[Bioc-devel] Newly proposed version bump plan
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