RFC: no automatic updates of packages with major version chan ge

Liaw, Andy andy_liaw@merck.com
Tue, 29 Oct 2002 08:03:39 -0500


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