Liaw, Andy
2002-Oct-28 13:12 UTC
RFC: no automatic updates of packages with major version chan ge
Is it possible to have a slightly more elaborate description, such as: BackwardCompatibleTo: x.x-x and if the new version is _not_ backward compatible, this would be the current version number? Just my $0.02... Andy -----Original Message----- From: Torsten Hothorn [mailto:Torsten.Hothorn@rzmail.uni-erlangen.de] Sent: Monday, October 28, 2002 7:25 AM To: ripley@stats.ox.ac.uk Cc: Friedrich.Leisch@ci.tuwien.ac.at; r-devel@stat.math.ethz.ch Subject: Re: RFC: no automatic updates of packages with major version change 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 carefulabout> > 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 CRANmaintainers> > 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 downloadthe> > `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 -- Readhttp://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 -- Readhttp://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 -- Readhttp://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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. _._ ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ============================================================================= -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Liaw, Andy
2002-Oct-29 13:03 UTC
RFC: no automatic updates of packages with major version chan ge
My understanding is that API needs to be a documented part of the software. In the current R packaging system, there doesn't seem to be a way to document interface to compiled code (i.e., what routines can be called and how to call them) except in the comments, so I'd think calling compiled code in other packages is not encouraged. I should think people realize that undocumented parts of the software are subject to change without notice. People who make use of such things ought to know they are treading on thin ice, IMHO. Just my $0.02... Andy -----Original Message----- From: Berwin Turlach [mailto:berwin@jacksonia.maths.uwa.edu.au] Sent: Monday, October 28, 2002 8:22 PM To: r-devel@stat.math.ethz.ch Subject: Re: RFC: no automatic updates of packages with major version change>>>>> "BDR" == <ripley@stats.ox.ac.uk> writes:BDR> Now, we could throw the onus on the maintainers to add a BDR> BackwardsCompatible:FALSE BDR> flag to the DESCRIPTION file, if people really think that BDR> would be easier. I wouldn't not find this easier, perhaps even not feasible. One reason is that, e.g., the "tseries" package depends on the "quadprog" package (S original by me, ported to R by Andreas Weingessel). When I finally get around to update that package and release a new version, I might be able to guarantee that the functions that I meant to be the API are backwards compatible but short of analysing the "tseries" code, I could not guarantee that the new version will not break "tseries". E.g., it could be that "tseries" calls the FORTRAN code of "quadprog" directly and doesn't use "quadprog"s R interface to the FORTRAN code. Also, every larger package has functions it it that build the API, but also functions that are helpful for the "main" functions and are not for direct use by the user. For example "merge.formula" in the package "lasso2". The manual says that is is not intended to be called directly by the user. But how should the maintainer now if everybody follows this request? Thus, if this function were to change during a revision in a major way but not the functions that are meant to build the API, would this mean that the new version is backward compatible? Best wishes, Berwin ========================== Full address ===========================Berwin A Turlach Tel.: +61 (8) 9380 3338 (secr) School of Mathematics and Statistics +61 (8) 9380 3383 (self) The University of Western Australia FAX : +61 (8) 9380 1028 35 Stirling Highway Crawley WA 6009 e-mail: berwin@maths.uwa.edu.au Australia http://www.maths.uwa.edu.au/~berwin -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. -.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. _._ ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ============================================================================= -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._