Philippe Grosjean
2002-Oct-28 13:06 UTC
no automatic updates of packages with major version change
>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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Jeff Gentry
2002-Oct-28 17:03 UTC
no automatic updates of packages with major version change
> 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,Another thing you can do for now is to maintain multiple R library directories. You would just have to be careful with the .libPaths(), etc. This doesn't solve the problem of having them simultaneously loaded, but for installs it will work. -J -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._