R 2.0.0 will require rebuilding of r-cran-* packages

[Dirk Eddelbuettel <edd@debian.org>]

Fellow r-(cran|noncran|other|bioc|omegahat)-* package maintainers,

GNU R 2.0.0 will come out in early October, and, as always, contains quite a
few changes and improvements. Of particular interest is the changed
behaviour for loading packages which, among other things, makes startup a
lot faster.  For a summary of changes relevant for package authors (i.e. our
upstream contacts, see http://developer.r-project.org/200update.txt). With
that, we can expect new upstream versions for most packages.

It also means that the five of us *must* rebuild all the 59 r-cran-*,
r-noncran-*, r-other-*, r-bioc-* and r-omegahat-* packages we maintain.  For
this we need a version of R 2.0.0 (or a pre-release). Now, given that we
cannot have two versions of R in the same flavour of unstable or testing at
the same time, and that the most recent maintenance build of R 1.9.1 has not
quite made it to testing (9 days, but waiting on mips), I have uploaded my
initial Debian packages of the alpha release of R 2.0.0 itself to
'experimental'.  [ Note that I built the packages on Sunday, but only
uploaded them earlier today -- so mirrors may need to catch up. Sorry about
that. ] I will continue to upload to experimental at least until
r-base_1.9.1-3 and its packages is in unstable.

So one strategy would be to 

a) fetch the current r-base_1.9.1.alpha.20040906-1 first build R 2.0.0 alpha,
   or any later release, from 'experimental' and to release updated packages
   -- with Build-Depends on this or later and matching Depends -- and to
   upload into 'experimental' so that ftp-master can push out to 'unstable'
   at our request; or else we could
   
b) wait maybe two more weeks until R 2.0.0 pre-builds will be in unstable,
   also ensure good Build-Depends and Depends as above, and release into
   unstable.
   
I prefer b), but thought I'd throw this out for discussion in case I am
overlooking something.

Comments?

Thanks, Dirk

PS  Steffen: two of your packages are a minor release or two behind upstream,
             and qtl needs to depend on r-cran-rmysql, not r-cran-mysql.

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx