Re: GEP-4 : Versioning and branching rules proposal

[Malcolm Tredinnick <malcolm commsecure com au>]

On Thu, Sep 26, 2002 at 11:51:59PM +0200, Frédéric Crozat wrote:
> 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).

It would be good if 'T' digit was optional here (can be omitted when 0).
We are starting to get into the realm of seriously long verison numbers
and I can't see the benefit of having a fourth digit outside of
development times. Although, reading your comments below I think I see
why you want it (maybe).

Also, allowing foo-X.Y.0 to be released ahead of GNOME X.Y is asking for
trouble. We saw exactly this in the lead up to GNOME 2.0 where libgnome
(to pick but one example) was released, then something happened that
required a change (there was a translation showstopper, from memory) and
it required a 2.0.1 release and so on.

It is, after all, possible that a bug is found in a release candidate
that will block the platform release.

I think requiring possibly one spurious release for release candidates
-- X.(Y-1).90+ -- and one more for "final" -- X.Y.0 -- is not too
onerous and walks a nice line between consistent version numbering and
allowing for bugs to fixed.

>      * Each  new release of modules based on X.Y branch will be
> versioned as X.Y.0.T.

When not version them as X.Y.Z. This will not cause a clash with
development for the next major GNOME release, since we increment Y in
that case. For example (imagining this system to be already in place),
we would have foo-2.0.Z for 2.0 bugfixes and and foo-2.1.Z for
development work leading up to GNOME 2.2.

Or does this not handle, say, the GNOME 2.0.2 release properly (which it
seems your above scheme does not either).

>      * Modules don't need to be re-release if the only change are the
> version number

So you will still get a release with the version numbering out of sync.
Maybe you need to add "except for a GNOME X.Y release when all modules
must be versioned as X.Y.0"? The ChangeLog in these cases can then say
"bumping version number for platform release" and that will only be an
isolated entry, so easy to understand.

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

Maybe this is the answer to my question about GNOME 2.0.2 above, I'm not
sure. Help?!

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

Personally, I think it's reasonable to keep it as "proposed solution".
But I'm not losing much sleep at all over the difference between the
so-called requirements and action GEPS, since sometimes they are
legitamtely folded into one (otherwise we are going to be sprouting GEPs
like the plague).

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

Thanks for the notes.

Cheers,
Malcolm