[Bioc-devel] SUGGESTION: BioC version (e.g. 2.13) to also follow the x.y(.z) version scheme of Bioc packages
On Wed, Oct 16, 2013 at 12:20 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:
----- Original Message -----
From: "Henrik Bengtsson" <hb at biostat.ucsf.edu> To: "bioC-devel" <bioc-devel at stat.math.ethz.ch> Sent: Wednesday, October 16, 2013 11:11:57 AM Subject: [Bioc-devel] SUGGESTION: BioC version (e.g. 2.13) to also follow the x.y(.z) version scheme of Bioc packages Hi, the new Bioconductor 2.13 release, aka "BioC 2.13", is out. Previous release was 2.12 and before that 2.11 and so on. Have you considered to follow the x.y(.z) version scheme of BioC packages [http://bioconductor.org/developers/package-guidelines/#versions] for this too, i.e. letting the stable/release version to always have an even 'y' in x.y, and the devel version to always have an odd 'y'?
The next version of BioC (current devel, to be released next spring) is 2.14. It will still be 2.14 when it is released. In other words, it has the same version number whether it's devel or release. Maybe you are suggesting that this situation change, and that even 'y' always indicates a devel version, and that we bump the version of BioC when we do a release (we currently don't do that).
I believe you meant to write "...that *odd* 'y' always indicates a devel version". If so, yes.
I think this would add to the confusion rather than simplify. The way things are now, I can be confident that the next release of BioC will be 2.14. With the proposed way, I'd need to think, well, it will be 2.15 until release and then it will be 2.16, and then the next devel will be 2.17 which will be 2.18 when it is released, and so forth.
But, that's how it works for BioC packages - the same implementation that had version 1.13.3 in devel, gets bumped to 1.14.0 when it's released. The odd/even version numbers of BioC makes it easy to know when you work to/require a devel version of a package or not. I'm looking for an analogous way for the "BioC" version. My main argument would be that some of the core BioC packages (Biobase, BioCInstaller) could then reflect/trace the version of the BioC project itself. As it is now, you cannot look at the BioC version and infer whether it is a release or devel version. You can only do this by looking it up manually online, but it cannot be programmatically tested for. The way I see it is that the BioC version is currently now only a label used for communication and in some URLs. Also, one day the same BioC version is devel, the next day it's release. I guess this one of the reason why R decided to stop mentioning the version number for R devel and instead simply call it "R devel (to become 3.1.0") . The analogue for BioC, and an alternative to my suggestion, would to never use a version number for the current devel, but to call it "BioC devel (to become 2.14") and reserve the numbers to the release version. /Henrik
Dan
Also, The Biobase package is directly or indirectly used by many of the Bioconductor packages. This would make it a natural candidate for have a version number that reflects the BioC version, i.e. when the Biobase package gets version 3.0.z in release BioC 3.0, while it gets version 3.1.z in devel BioC 3.1. That would provide a natural way to specify that a package depends on a certain BioC version (e.g. Biobase (>= 3.0.0)), at least for those packages directly depending on Biobase. Of course, an alternative would be to have dummy package BioC for just this purpose. BTW, it would also make sense if the BioCInstaller package version would reflect the BioC version. All this would be possible if BioC itself followed the same version schema as the packages.
/Henrik
_______________________________________________ Bioc-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel