RFC: no automatic updates of packages with major version change

[Torsten Hothorn]

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. 

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