Skip to content

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

5 messages · Michael Lawrence, Dan Tenenbaum, Henrik Bengtsson +1 more

Original
Henrik Bengtsson
# 
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'?

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
Dan Tenenbaum
# 
----- Original Message -----
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
Henrik Bengtsson
#
On Wed, Oct 16, 2013 at 12:20 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:
I believe you meant to write "...that *odd* 'y' always indicates a
devel version".  If so, yes.
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
Nicolas Delhomme
# 
Just to be a devil's advocate, it's easy to find if you are using a devel (or not) version by looking at the BiocInstaller version number (or any Bioc package for that matter):

devel <- ifelse(packageVersion("BiocInstaller")$minor%%2L == 0,FALSE,TRUE)

That's actually what the BiocInstaller packages does at startup (lookup its zzz.R file) to decide what package version to install in your environment, devel or not. 

I suppose it would be easy though to have a function implemented in BiocInstaller or Biobase to check that, e.g.

isDevel <- function(){
	## some more checks obviously
	ifelse(packageVersion("BiocInstaller")$minor%%2L == 0,FALSE,TRUE)
}

Dan, do you think that would be a valid addition?

On the general issue, I agree with Dan that changing the scheme would create more confusion to the general - non developer - R user. I'm not sure I see the point of your last argument, even if we call it Bioc-devel, we all know it will be 2.14, as we all know that the next R version will be 3.1.0 (or at least it is extremely likely to be so unless unexpected changes make it 4.0.0 or not enough significant modifications make it 3.0.3). That flexibility in the R version numbering is IMO not necessary for Bioc, as there will always be significant changes from one version to the next. 

I think the even/odd numbering should remain as it is for both Bioc and the packages, because general users are not used to the even=stable; odd=devel paradigm that is useful to us developers. I may as well just be a creature of habits ;-)

Nico

---------------------------------------------------------------
Nicolas Delhomme

Genome Biology Computational Support

European Molecular Biology Laboratory

Tel: +49 6221 387 8310
Email: nicolas.delhomme at embl.de
Meyerhofstrasse 1 - Postfach 10.2209
69102 Heidelberg, Germany
---------------------------------------------------------------
On 17 Oct 2013, at 00:19, Henrik Bengtsson wrote: