Re: GEP-4 : Versioning and branching rules proposal

[Frédéric Crozat <fcrozat mandrakesoft com>]

Le jeu 26/09/2002 à 19:15, Malcolm Tredinnick a écrit :
> On Thu, Sep 26, 2002 at 06:54:07PM +0100, Michael Meeks wrote:
> > On Wed, 2002-09-25 at 15:47, Jody Goldberg wrote:
> > > 1) a versioning scheme that can will support gnome version & package
> > >    version in all the phases of a release.
> > > 
> > > 2) not bumping things with no apparant change
> > > 
> > > In my opinion (1) is more important.  Indeed there is some change
> > > in a package when its version gets bumped to .0 for a release even
> > > though its code has not changed.  That bump indicates that it has
> > > been tested with its new sibling packages (the rest of gnome).
> > 
> > 	Of course, however - from what I remember of the proposal, there were
> > even more versions, and they changed even more frequently than most
> > people release packages [ with minor fixes ] currently.
> 
> The GEP proposes that each new platform beta and release candidate will
> require a new library release with the macro version number changed.
> That does seem a little excessive when a library is basically stable
> (and I tend to agree with Michael's comment that it leaves people
> wondering what has changed. The ChangeLog will only say "released new
> version", after all).

I think this point is the main problem in the proposal..

To resolve all the objections, I think we need to drop the
micro-versioning before stable release, and also change the requirement
on numbering.. 

Here is a modified proposal :

When  developing X.Y version, snapshot releases should be versioned as
   X.(Y-1).Z

Z must follow the following rules :
     * each new release of the module should only increment Z.
     * at release  candidate time,  Z should be superior to 90.

When GNOME X.Y is released as final (or when module maintainer consider
developement finished for this module for X.Y timeframe) :
     * modules should be released as X.Y.0.0 (ie Z = 0).
     * Each  new release of modules based on X.Y branch will be
versioned as X.Y.0.T.
     * Modules don't need to be re-release if the only change are the
version number

When  a  new  version  of the platform is released on X.Y branch, if new
release need to be done on this module, Z is
incremented and T reset to 0.

I really think we should try to keep the micro-versioning after first
stable release, otherwise we loose the interest of common versioning
(but remember, this is not part of the requirements, it is just part of
the proposed solution...)

> A general comment on this GEP: in theory, the discussion period closes
> today (or tomorrow for people in far away places). However, there are a
> number of unresolved issues in section four of the GEP. Some hint about
> how the owner (or responsible people) would like to resolve those might
> be nice.

Oops, I forgot to comment on that..
*GNOME platform and modules releases too deeply linked => this is no
longer part of the requirements but of the "Proposed solution".. Maybe I
should rename "Proposed Solution" to "Implementation example"..
Therefore, it will be up to module maintainer to choose X.Y (if they
want to have X.Y = GNOME Platform X.Y, great :)

*Bumping releases when nothing has changed => I think I've just fixed
this one :)

*Branching clarification => Fixed with my previous modification in the
GEP.. I should add that in the comment.. 

> My general feeling is that everybody agrees branching guidelines are
> good and module versioning guidelines are probably good. But we don't
> seem to have nailed down the versioning guidelines very well (the
> branching portion doesn't seem very contentious).

It is almost ok.. We can finish it :))
-- 
Frédéric Crozat
MandrakeSoft