RFC: no automatic updates of packages with major version change
Mon, 28 Oct 2002 11:28:30 +0000 (GMT)
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
flag to the DESCRIPTION file, if people really think that would be easier.
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 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
> 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
> > 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 http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> > Send "info", "help", or "[un]subscribe"
> > (in the "body", not the subject !) To: firstname.lastname@example.org
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> 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: email@example.com
Brian D. Ripley, firstname.lastname@example.org
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 http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com