RFC: no automatic updates of packages with major version change

[Kurt Hornik]

>>>>> Torsten Hothorn writes:

>> 
>> We (Kurt Hornik, Brian Ripley & I) want to propose the following
>> change to the automatic package updating mechanisms of R: A major
>> version number change of a package will by default disable the
>> automatic updating of packages, because the interface of the package
>> might have changed and hence old code might not run anymore.
>> 
>> A recent example was the release of mclust version 2.0, which is not
>> fully compatible with mclust 1.x (functions got removed, others added
>> and arguments renamed etc).
>> 
>> Of course it is absolutely OK for a package to change its API,
>> otherwise improvements would be rather hard, but it should be easier
>> for users to stay with the old version until they have figured out
>> what exactly the effects of an upgrade would be.
>> 
>> We want to define a "major version number change" as a change of the
>> first digit of the version number, such that 1.1.1 -> 2.0.0 is a major
>> change, while 1.1.1 -> 1.2.0 is not. An exception will be that a move
>> from 0.x to 1.x is no major change (because the 0.x series is read as
>> "working towards 1.0").
>> 

> This definition requires EVERY package maintainer to be VERY careful
> about version numbers / API changes and I guess some of us (including
> me) may fail this exercise.

> I suggest the following definition: the API of a package changed iff
> the example code of the previous version of the package does not run
> without an error. In contrast, the results of the computations may
> differ. Of course, this induces additional effort to the CRAN
> maintainers but it should be possible to extract and check the
> examples of a CRAN package against a new version BEFORE uploading the
> new version to CRAN. In addition, a flag `APIChange TRUE / FALSE'
> visible to `update.packages' is needed.

> Or should this be part of R CMD check? Maybe R CMD check can download
> the `official' release from CRAN to check against an API change and
> give a warning?

All of this might be doable but I am not sure it is worth the effort.

If a package has basically no examples then it can change things in
all possible ways without breaking its examples.  So I think that the
condition is an 'if' but far far away from an 'only if'.

I would assume that most package writers know when they change their
code in incompatible ways.

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._