[Bioc-devel] Proposed version bump plan for 1.7 release
On 9/26/05, Seth Falcon <sfalcon at fhcrc.org> wrote:
On 26 Sep 2005, colin at colinsmith.org wrote:
On Sep 26, 2005, at 11:23 , Seth Falcon wrote:
0. All packages have an x.y.z version number 1. All packages in the 1.7 release will be bumped to x.(y+1).0. This will communicate to users that the package is part of the release and has been verified to work with R 2.2.0. 2. Once the release branch has been made, all packages will be bumped to x.(y+2).0 to indicate the beginning of the BioC 1.8 devel line.
I have two suggestions for the currently proposed bike shed: #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.
#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.
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). best, -tony blindglobe at gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).