[Bioc-devel] Proposed version bump plan for 1.7 release

[Seth Falcon]

On 26 Sep 2005, colin at colinsmith.org wrote:
> I think skipping to even version numbers would be a bit of a short
> term loss of consistency in exchange for greater long term clarity
> about version numbering. The whole point of this change is to
> distinguish release vs. developmental packages. Piggybacking on an
> established convention would help in that regard. With the even-odd
> convention, you only need to know the version number you currently
> have to know whether you have a release/devel package. While you
> could guess that a x.y.z (z != 0) package is devel, if we ever start
> incorporating bug fixes in to the release branch, that guess
> wouldn't work.

We do want to fix bugs in release and that is one critical aspect of
the whole version bumping business :-)

> For example, the DynDoc package is now at version 1.6.0, which it
> received after the version bump at the last release. Judging from
> the version number, I'm guessing that there have been no changes to
> that package since then. After release 1.7, the devel version number
> in SVN would be bumped to 1.7.0. However, if at the release 1.8, the
> version number was still 1.7.0. The SVN revision where DynDoc was
> 1.6.0 would be tagged as RELEASE_1.8 (or whatever) and 1.7.0 would  
> continue to be the version in the devel repository.

This makes some sense and I agree that allowing package version
numbers to stagnate makes the version numbers more meaningful.  

Our current scheme has some simplicity: development happens on trunk.
Releases are cut from trunk.

If we did the above version stagnation plan, this would no longer be
true: release is cut from trunk except when package in trunk has z ==
0, then look at revision in previous releases branch and use that.

Other than the yuck this imposes on the release manager (that would be
me) the potential for confusion and dropped changes (A change does go
into devel, but z wasn't incremented) is non-zero.  

> On the R CMD check page on the Bioconductor web site, I count at
> least 40 packages that have an x.y.0 version number and still pass R
> CMD check. While some authors may have manually bumped their version
> number to x.y.0 since the last release, I'm guessing that the large
> majority of those packages haven't changed at all since 1.6 and
> won't need to change for 1.7. Allowing for the version numbers to
> stagnate when packages stagnate makes the version numbering system
> more useful.

Having thought on this a bit more, I think we really want all packages
to increment their version number.  The binary packages that we
distribute are linked to a particular R version.  So a bumped version
indicates that the package is suitable for the currently released R.
And helps avoid the confusion that ensues when users want to use old
binaries with new R installs.

+ seth