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