Hi, Why not take the following links a bit further:
http://bioconductor.org/js/versions.js http://bioconductor.org/bioc-version And just have something that returns a JSON response with more detail ... perhaps something like: { "R2_0": { ... }, "R2_15": {"release": 2.12, "devel": 2.13}, "R3_0": { "release": 2.13, "devel": 2.14}, "R3_1": { "release": 2.14, "devel": 3.0}, // someway to identify R-devel "R-devel??": { ... } } And maybe put some utility function in BiocInstaller to parse that. If you're feeling ambitious, you could go down to the R3_0_2 level of granularity, I guess. Just a thought, -steve On Wed, May 7, 2014 at 10:57 PM, Dan Tenenbaum <dtene...@fhcrc.org> wrote: > > > ----- Original Message ----- >> From: "Martin Morgan" <mtmor...@fhcrc.org> >> To: bioc-devel@r-project.org >> Sent: Wednesday, May 7, 2014 10:07:10 PM >> Subject: Re: [Bioc-devel] Tracking Current release >> (http://www.bioconductor.org/packages/current redirect to >> http://www.bioconductor.org/packages/2.14) >> >> Hi Don -- >> >> On 05/07/2014 06:21 PM, Don Armstrong wrote: >> > I maintain a collection of Debian packages of CRAN and BioC[1] for >> > public use; currently, whenever BioC makes a new release, it >> > requires >> > manual intervention for me to point at the new release location. >> > >> > It would be helpful if there was a >> > http://www.bioconductor.org/packages/current redirect to the >> > current >> > release, or if there was another easily parsable method to obtain >> > the >> > current bioC release version. >> >> Bioconductor releases are tied to R versions and the 'current' Bioc >> for a >> particular R, in a brand new installation, is >> >> source("http://bioconductor.org/biocLite.R";) >> biocVersion() >> >> (this is BiocInstaller::biocVersion(), where the biocLite.R script >> has arranged, >> modulo MITM concerns below, to install the version of the >> BiocInstaller package >> relevant to your version of R). I personally think of this as the >> canonical >> location, but... >> >> http://bioconductor.org/packages/release goes to the current release >> 'biocViews', with packages under release/ being the current release >> versions. >> http://bioconductor.org/bioc-version is probably what you'll end up >> using >> (though I believe it's hand curated), and > > > This is automatically generated, as is > http://bioconductor.org/js/versions.js > which also includes the devel version number. > > Dan > >> tools:::.BioC_version_associated_with_R_version (this is a function >> in R-3.1) >> gives the version that R thinks is the current BioC version (this can >> become >> stale, e.g., R-3.0.1 was released when BioC-2.12 was the current >> version, but >> part way through the R point release BioC 2.13 became available [or >> at least, >> that's how I remember it]). >> >> > FWICT, neither http://bioconductor.org/getBioC.R nor >> > http://bioconductor.org/biocLite.R encode that information >> > either,[2] >> > unless that's what CURRENT_R_DEVEL_VERSION <- "2.14.0" is supposed >> > to >> > be. >> > >> > >> > 1: http://debian-r.debian.net/ >> > >> > 2: I should also point out that the current methodology of >> > installing >> > BioC using code from a remote host is problematic as it exposes >> > users to >> > MITM attacks because it is never checked for authenticity via PGP >> > or at >> > the very least, SSL. As such, sourcing that script and using >> > variables >> > populated by it isn't really acceptable. >> >> Of course this is a valid concern and we can work toward a more >> secure approach. >> >> Perhaps I could take the opportunity to ask a naive question about >> debian binary >> distributions of R. What is the directory into which packages are >> installed by >> sudo? In particular, are they unversioned, /usr/lib/R/library etc, as >> opposed to >> say /usr/lib/R-3.1/library ? I'm asking because a number of users >> seem to show >> up with say R-3.1 reporting a mix of R-3.1 and R-3.0.2 packages, >> usually to ill >> effect; this is not necessarily likely for user-installed packages, >> because the >> system directories won't be writeable and R will prompt with a >> versioned >> directory ~/R/x86_64-unknown-linux-gnu-library/3.1 as the location to >> install >> libraries. I'm wondering if mixed package versions would happen if >> their package >> manager failed to remove previously installed packages from the >> /usr/lib/R/library directory, or if the user installed multiple >> versions of R. >> Of course this could merely reflect users installing R without the >> help of >> package managers, and either way it might point to changes in the way >> R installs >> itself. >> >> Martin >> >> > >> >> >> -- >> Computational Biology / Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N. >> PO Box 19024 Seattle, WA 98109 >> >> Location: Arnold Building M1 B861 >> Phone: (206) 667-2793 >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Steve Lianoglou Computational Biologist Genentech _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
