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

[Colin A. Smith]

On Sep 26, 2005, at 12:21 , A.J. Rossini wrote:

>>> #1) Add the additional condition that y is odd, resulting in even-
>>> numbered releases and odd-numbered development branches, similar to
>>> other projects.
>>
>> The problem is that right now we have a mix of even and odd y's.  We
>> could increment y to the nearest even number for release and the next
>> number for devel.  Is that what you are suggesting?

Yes.

> +1 for Seth -- there isn't a consistent numbering system, and it will
> not really be a good change.  I like just the x.(y+1).0 by default.
> However, I suggest doing this at the last possible moment (i.e. hours
> before release announcement), to avoid premature increments.

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.

>>> #2) At the time of the next release, if the devel version number is
>>> still x.(y+2).0, indicating there were no changes to the package
>>> between releases, then the version included in the next release is
>>> kept at x.(y+1).0. Otherwise, it might give a false sense of  
>>> progress
>>> where there was none.
>>
>> Can you clarify #2, please.  Let's toss the x.y.z that I started and
>> use the fictitious foo and bar packages.  For discussion, the curretn
>> devel version of foo is foo_1.2.3 and bar is bar_1.3.1.

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.

> I think the point is that if the package hasn't changed, that it
> shouldn't change.  I disagree, in that most packages should be
> updated, if even slightly, to accomodate changes in R (at least for
> the last few R releases!).  However,  I think that if
>
> 1.2.3 becomes 1.3.0 becomes 1.4.0, it ought to be clear that nothing
> is really changing (but of course, I don't see how one could really
> know this in an obvious, clean fashion).

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.

-Colin