[Bioc-devel] Proposed version bump plan for 1.7 release
Colin A. Smith
colin at colinsmith.org
Mon Sep 26 21:58:36 CEST 2005
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?
> +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
>>> #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
>>> 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.
More information about the Bioc-devel