[Rd] Interaction between callNextMethod() and selectMethod()

[peter dalgaard]

On Aug 5, 2012, at 04:16 , Simon Urbanek wrote:

> 
> On Aug 4, 2012, at 9:49 PM, Hervé Pagès wrote:
> 
>> On 08/03/2012 11:44 PM, peter dalgaard wrote:
>>> 
>>> On Aug 4, 2012, at 01:24 , Hervé Pagès wrote:
>>> 
>>>> BTW, it's funny that the VERSION file in the R source tree says:
>>>> 
>>>> hpages at latitude:~/src/R-2.16.r59963$ cat VERSION
>>>> 2.16.0 Under development (unstable)
>>>> ^^^^^^
>>> 
>>> What's funny about that? We no longer display the number on startup and at some point we may not even use it for an actual release, but there needs to be a number to test "R >= 2.14.0"-style dependencies and such.
>>> 
>> 
>> What's funny is that even if we try to pretend that the version
>> number doesn't matter, it actually does matter. Not only for
>> "R >= 2.14.0"-style dependencies and such, but also for human communication:
>> 
>> - Can't install that package!
>> - Works for me. What version of R are you using?
>> - "Unsuffered Consequences"
>> - I'm using "Roasted Marshmallows", you should upgrade to
>> that one.
>> - I'm confused I thought I was running the latest.
>> - No "Roasted Marshmallows" is the latest.
>> - Are you sure? How do you know?
>> 
>> etc, etc...
>> 
>> It reminds me of Mozilla plans to hide Firefox version:
>> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=678775
>> 
>> AFAIK they finally abandoned it :-)
>> 
> 
> I agree. Currently R-devel doesn't show the version number and that makes sense for two reasons: let's say today R-devel's internal version is 2.16.0 but such release doesn't exist yet so you can't call R-devel that in any case that may be referenced later (because then there will be 2.16.0 release at some point which is different from the R-devel that was referred to). Also we don't know for sure if the next release will be 2.16.0 or let's say 3.0.0.
> 
> That said, I was surprised that Peter said "for an actual release" (I'm not sure he meant it in the way you interpreted it, though) - I think it's slightly annoying that R.version.string in R-devel doesn't contain the version number (because it makes it slightly more complicated to get the version number in scripts), but not having it or showing it for releases would certainly be fatal but I did not see any reason or discussion about such a move.

"Actual release" meant exactly what you say: There's no 2.16.0 release yet, and (in principle) the next one might be 3.0.0. 

The number is there, though. For one thing, install.packages() would break without it. We just do not show it so that people will not mistake it for a release code. (Simon: You don't want to parse R.version.string, the information is already in the other fields of R.version.)

R-devel is not a release (and neither is R-patched, for that matter), There is no way in which it is reasonable to call R-devel "the latest R" etc. What it is is a snapshot of the current sources; it is not intended for production use. Do so and you'll suffer the consequences... It is by definition unstable: It may happen that someone forgets to add a new file while modifying another so that R no longer builds for anyone except himself -- we don't need 100 bug reports on "R 2.16.0" on that account. Or there can be platform issues or unexpected CRAN repercussions. 

Notice that since R-devel and R-patched are constantly changing, the formal version number is insufficient to identify the set of sources, and we need the Subversion revision number to identify the exact set of sources.  

For basically the converse reasons, R (source) releases can not be changed retroactively. So until the next release, bug fixes go to R-patched or R-devel, which is why we ask people to at least check those versions (or just their NEWS files) before submitting bugs.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com