Re: GEP-4 : Versioning and branching rules proposal

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

Le ven 27/09/2002 à 00:06, Malcolm Tredinnick a écrit :
> 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).

Yes, I was wondering if we should force X.Y.0.0 or if X.Y.0 is enough..
I think we can keep X.Y.0 (T optional when 0)..

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

I'm not sure this requirement is needed :
One "final" (or stable) has been reached (ie Z = 0), following releases
should versioned as X.Y.0.T, therefore we know they are part of the
"stable" versions, not the devel version.. 
I don't want to force all maintainers to re-release their modules just
because platform is released :)

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

Rule of thumb : never reply to mail at midnight :))

I think I need to separate initial release of the platform (X.Y) and
subrelease of the platform (X.Y.Z).. 

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

ok for this one..

 
> > 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?!

Exactly..

I wonder : maybe I should modify the way versioning is presented in a
"range" way :

developement timeframe : X.(Y-1).0 <= version <= X.(Y-1).90 
release candidate timeframe : X.(Y-1).90 <= version <= X.Y.0 (with
possible X.Y.0.T if needed)
stable timeframe : X.Y.Z(.0) <= version  < X.Y.Z+1(.T) 


-- 
Frédéric Crozat
MandrakeSoft