[Bioc-devel] Newly proposed version bump plan

[Gordon Smyth]

At 08:00 PM 30/09/2005, bioc-devel-request at stat.math.ethz.ch wrote:
>Date: Thu, 29 Sep 2005 08:00:27 -0700
>From: Seth Falcon <sfalcon at fhcrc.org>
>Subject: Re: [Bioc-devel] Newly proposed version bump plan
>To: bioc-devel at stat.math.ethz.ch
>Message-ID: <m2y85fex6c.fsf at macaroni.local>
>Content-Type: text/plain; charset=us-ascii
>
>On 29 Sep 2005, maechler at stat.math.ethz.ch wrote:
> > Hmm, one thing that's not been entirely clear to me:
> >
> > - Assume package "abc" gets version 1.2.3 (even number '2') for BioC
> >   1.7
> > - according to the above it gets     1.3.z  (z=0 or z=1 or z=3 ?)
> > for "devel" subsequently.
> > - Now assume there is no change whatsoever to "abc" till spring 2006
> > when Bioc 1.8 will happen.
> > I assume your scheme above means that "abc" will be released
> > as "1.2.3" in BioC 1.8 and stay as 1.3.z in "devel" , right ?
>
>Good question.  Here's a clarifiction of what I was thinking:
>
>                              devel just
>current    1.7     devel     before 1.8    1.8
>=======    =====   =====     ==========    =======
>1.2.4      1.4.0   1.5.0     1.5.4         1.6.0
>1.3.4      1.4.0   1.5.0     1.5.1         1.6.0
>1.2.4      1.4.0   1.5.0     1.5.0         1.4.0 (no changes since 1.7)
>
>So when y get incremented for the release, we set z <- 0.  And the
>first version number in the following devel line will also have z==0.
>
>A package that has z==0 in devel just before a release is unchanged
>and won't get version bumped for the release.
>
> > I do hope that something very close to the above will be
> > adopted.
> > Thank you, Seth!
>
>Thanks for the feedback.  So far I haven't received complaints, which
>may mean package maintainers aren't reading their mail ;-)
>
>+ seth

I read enough of my email :-) and was happy with the bumping plan.

Actually I think the fact that there is a clear policy, and that people can 
see what it is, is more important than the details of the policy itself. So 
it is important that the policy should be written down somewhere publicly 
available once it is finalised (as you're probably already planning to do). 
The practice of updating official release versions after the official 
release date, which is what leads to the need for bumping in the first 
place, may be unexpected to many users, especially given that the release 
version number does not change. Some guidelines to users as to what 
circumstances they may need to revisit their Bioc installation would be 
good, and I guess the package numbering system associated with the bumping 
policy is designed to facilitate this.

Cheers
Gordon