From Kurt.Hornik@wu-wien.ac.at  Mon Oct 28 11:54:47 2002
From: Kurt.Hornik@wu-wien.ac.at (Kurt Hornik)
Date: Mon, 28 Oct 2002 12:54:47 +0100
Subject: RFC: no automatic updates of packages with major version change
In-Reply-To: <Pine.LNX.4.21.0210281107130.7939-100000@artemis>
References: <15804.65096.834736.160738@celeborn.leisch.at>
 <Pine.LNX.4.21.0210281107130.7939-100000@artemis>
Message-ID: <15805.9607.993910.88576@mithrandir.hornik.net>

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


RFC: no automatic updates of packages with major version change
Kurt Hornik