RFC: no automatic updates of packages with major version chan ge

Torsten,

I did suggest that test at an earlier stage in the discussions.  But some
packages have so few examples they may well pass and have repercussions.

I do think we need to address the problem: lattice_0.6-5 is another
example of an API change.

Now, we could throw the onus on the maintainers to add a

BackwardsCompatible:FALSE

flag to the DESCRIPTION file, if people really think that would be easier.

Brian

On Mon, 28 Oct 2002, Torsten Hothorn wrote:

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

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

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.

addition, a flag `APIChange TRUE / FALSE' visible to `update.packages'

needed.

Or should this be part of R CMD check? Maybe R CMD check can download

`official' release from CRAN to check against an API change and give a
warning?

best,

Torsten

In case of a major change

*) update.packages() will warn the user if ask=TRUE, like

mclust :
 Version 1.1-7 in /usr/local/lib/R-contrib
 Version 2.0-1 on CRAN
 WARNING: major version number change
Update (y/N)?

*) if ask=FALSE, update.packages() will cowardly refuse the updates
 and issue a warning for all packages that have not been updated.

*) the same will be done for the methods working off packageStatus
 objects.

Note that we are already working on new package management tools which
should make it easier to have multiple versions of a package installed
simultaneously.

All comments are welcome.

Best,
Fritz

r-devel mailing list -- Read

Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:

r-devel mailing list -- Read

Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

r-devel mailing list -- Read

Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch