no automatic updates of packages with major version change

[Philippe Grosjean]

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

>...

>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 makes sense, otherwise, what would be the reasons of a "complex"
three-level granularity versioning system
X.Y-Z with:
- X being major changes implying *modifications* of the interface (I would
rather eliminate "might" in "might" have changed, otherwise, nobody will
ever know if something really changed or not, see hereunder!)
- Y being addition of new features, while staying fully compatible with the
previous version (with same X)
- Z being maintenance version (no new feature compared to same X.Y, but
correction of bugs).

If everybody conform strictly to this scheme, life will be much, much more
easier! The problem is that not everybody does... and we have X.Y versions
for some packages (what do they means?), or even 2002.X-Y (with 2002 being
the year, and perhaps X being the month [??] of release). All this is
confusing. It should be useful to explain more deeply the recommended
versioning system for R packages in R-exts.pdf.

I understand that, currently, major version 'X' is admitted to increase when
major changes are made, even when the upgraded package remains fully
compatible with the previous version (and this is the desired behaviour, of
course). So, my suggestion is allowing 'X' to increase *only* when
*incompatible* changes are made.

There is still a problem with this versioning system for R packages. When
somebody wants to keep an old major version to keep compatibility with old
scripts, and want also to install the brand new major version to start
exploring it. In this case, there is a conflict because both packages bear
the same name! The simplest solution would be to change the name of the
package (for 'PkgName' for version 1.Y.Z to 'PkgName2' for version
2.Y.Z,...) allowing two or more major versions to live in the same system,
as it was once the case for survival (and now for 'mclust' versus
'mclust1998', although in this case it is the old package that changes its
name, and this is a problem for scripts that use something like
'require(mclust)' and refer to the old interface!!!). There are still
possible confusion when both 'PkgName' and 'PkgName2' are loaded
simultaneously, because many functions are likely to have the same name in
both packages,... but at least, it solves a part of the problem.

Best,

Philippe Grosjean

...........]<(({°<...............<°}))><...............................
( ( ( ( (
 ) ) ) ) )      Philippe Grosjean
( ( ( ( (
 ) ) ) ) )      IFREMER Nantes - DEL/AO
( ( ( ( (       rue de l'Ile d'Yeu, BP 21105, 44311 Nantes Cedex 3
 ) ) ) ) )      tel: (33) 02.40.37.42.29, fax: (33) 02.40.37.42.41
( ( ( ( ( 
 ) ) ) ) )      SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (       e-mail: phgrosjean@sciviews.org
 ) ) ) ) ) 
( ( ( ( (       "I'm 100% confident that p is between 0 and 1"
 ) ) ) ) )                                L. Gonick & W. Smith (1993)
.......................................................................


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