[Bioc-devel] Newly proposed version bump plan

[Martin Maechler]

>>>>> "Seth" == Seth Falcon <sfalcon at fhcrc.org>
>>>>>     on Wed, 28 Sep 2005 17:20:13 -0700 writes:

    Seth> Hi all, After considering the discussion on this list,
    Seth> here is our current plan for version bumping:

    Seth> For future releases:

    Seth> 1. All packages have version number in format x.y.z

    Seth> 2. y is an odd number in devel and gets bumped to an
    Seth> even number for release.

    Seth> 3. If a package has not changed in devel, the version
    Seth> number will not be bumped.

This sounds very good and I'd be happy about such a scheme!

    Seth> What this means for now:

    Seth> 1. Packages need to move to an x.y.z scheme (see below
    Seth> for a list of packages that don't fit x.y.z at
    Seth> present).

    Seth> 2. For the BioC 1.7 release, we will bump y to the
    Seth> nearest even number.  To create the new line of devel
    Seth> for BioC 1.8, we will add 1 to the resulting release y
    Seth> number.  The version bumping will happen at the last
    Seth> second and be performed centrally by the release
    Seth> manager.

    Seth> 3. For the 1.7 release, everything in the release gets
    Seth> bumped to simplify the move to the even/odd scheme.
    Seth> In future releases, if a package is unchanged in
    Seth> devel, we will not increment the version just for the
    Seth> release.
   
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 ?

    Seth> Finally, if you find this plan sufficiently annoying,
    Seth> please let us know.  If there is sufficient outcry, we
    Seth> will ammend or cancel these plans.  Our goals are to -
    Seth> improve the consistency of the versioning scheme -
    Seth> make it easier for users to distinguish between
    Seth> release/devel - not annoy package developers

I do hope that something very close to the above will be
adopted.
Thank you, Seth!

Martin