RFC: no automatic updates of packages with major version change

Mon, 28 Oct 2002 14:08:26 +0100

Torsten Hothorn wrote:
> 
> On Mon, 28 Oct 2002 ripley@stats.ox.ac.uk wrote:
> 
> > 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.
> >
> 
> ok, I see.
> 
> > 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.
> >
> 
> yes, that would be better than just assuming API changes in every major
> release.

I would agree with that. By now the version is just required to be "a
sequence of at least non-negative integers separated by single `.' or
`-' characters" and can not necessarily be expected to follow the same
system as the R releases.
A field in the DESCRIPTION file is something package maintainers are
more used to, I guess. And obviously there are sometimes API changes
that do not occur when there is a major version number change...
Z

> Torsten
> 
> > 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 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?
> > >
> > > 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 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
> > > > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> > > >
> > >
> > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> > > 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
> > > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> > >
> >
> > --
> > 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 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
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> >
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> 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
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._