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

[A.J. Rossini]

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).