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

#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