[Bioc-devel] SUGGESTION: BioC version (e.g. 2.13) to also follow the x.y(.z) version scheme of Bioc packages

[Dan Tenenbaum]

----- 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 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.

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
>