Re: GEP-4 : Versioning and branching rules proposal

Le ven 30/08/2002 à 12:18, Frederic Crozat a écrit :
> Here is the announce for GEP-4 : versioning and branching rules for
> GNOME modules..
> Discussions should be done on desktop-devel list..

Sorry for not responding to all previous comments on my initial GEP but
I had too much work with Mandrake 9.0 finalizing process (rule of thumb
: don't start a GEP if you have other obligations :))

Thanks to Michael and many other suggestions, I've reorganised the GEP
to clearly separate requirements from proposed solution (I had many
difficulties to write a clean GEP at first since there wasn't many
available GEP at that time..)

Please comments..

I didn't modify the "let's use same version across all modules"
proposal, I prefer to hear more comments on that :)
Frederic Crozat
Title: REQUIREMENTS GEP 4: module versioning and branching guidelines for GNOME platform

REQUIREMENTS GEP 4: module versioning and branching guidelines for GNOME platform

This GEP contains guidelines maintainers should follow when versioning, tagging or branching modules which are part of GNOME platform.

1. Administrivia

Document Owner
Frederic Crozat
August 30, 2002
Discussion Period Ends
September 27, 2002
Discussion List
desktop-devel-list gnome org
Responsible Persons
Frederic Crozat, Havoc Pennington Nils Pedersen Michael Meeks Mark McLoughlin Seth Nickell Jacob Berkman

2. Requirements

2.1 Rationale

Why do we need guidelines for versioning, branching and tagging ?

During GNOME 2.0 release, several issues were raised such as :

2.2 Guidelines

Theses guidelines have been deduced from the encountered problems. They should not be seen as an inflexible and administrative polixy but a way to help module maintainers when they are doing releases.

GNOME Developer Platform modules maintainers are free to follow only tagging, branching or versioning guidelines.

If a module already has its own set of guidelines (like GTK+), is used outside GNOME scope (like libxml, ORBit..), it doesn't have to comply to these guidelines.

They will ease recognition for users, translators, vendors and any interested parties in GNOME development.

2.2.1 Versioning

Each new version should always be strictly superior to previous released version.

Non-digit characters (such as "beta", 'rc') should be avoided, as they tend to break version comparison on various packaging system ((they see 2.0.0beta > 2.0.0). It is prefered to add one level of versioning instead.

When issuing a new release, maintainer should tag the module as MODULE_NAME_VERSION_RELEASED.

2.2.2 Branching and tagging

When branching a module, a tag should always be created at branch point, based on the name of the branch : for branch foo-bar, tag should be FOO_BAR_ANCHOR.

A common branch name should be used across all modules of the platform for a specific release of the platform (for GNOME 2.0, branch name was gnome-2-0).

Once branching has occured, commit done to this branch should be also done on HEAD branch, to prevent regression when HEAD branch will be used for development.

When stable version of GNOME platform is released, corresponding branch should be created on relevent modules, with a common name for branch across modules. Maintainers may create this branch before stable version of platform is released (for instance when feature freeze is reached) or may defer branching until new developement is started on the module, long after stable platform is released. Maintainers are free to create micro-branch after each stable releases.

3 Proposed solution

3.1 Module versioning

Hypothesis : GNOME X.Y is the target release. Y will always be even for stable releases of the platform and odd for development version of the platform.

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

This only applies to modules which doesn't have either own versioning system and whose previous versions are below X.Y

Z and T must follow the following rules :

When GNOME X.Y is released as final :

When a new version of the platform is released on X.Y branch, Z is incremented and T reset to 0.

Example for GNOME 2.2 development :

3.2 branching and tagging

This branching and tagging rules are based on previous discussions in desktop-devel list.

Example :

If libgnome 2.1.5 is released, CVS module of libgnome will be tagged as LIBGNOME_2_1_5

Hypothesis : GNOME X.Y is the target release.

Example from GNOME 2.0 development :

4. Issues Raised During Discussion

4.1 GNOME platform and modules releases too deeply linked

Comments from Sander about the hardwired X.Y in platform modules == GNOME X.Y which should be dropped. It is too much anchored in its view in the present day and old long-standing gnome modules.

4.2 Bumping releases when nothing has changed

Comment from Mark and Nils about the fact current proposal requires a new release each time a GNOME Platform milestone is reached, even if nothing (code or translation) has changed since latest release. It is somehow related to comment 4.1.

4.3 Branching clarification

Comments from Mark about the fact branching rules states when a GNOME version is released, the module should branch. This shouldn't be set in stone. Some modules may wish to branch before that - e.g. when the feature freeze starts - or some modules may not wish to branch until a few more minor releases are done and some modules may never need to branch at all.

5. Decision and Rationale

None yet.

6. Amendments and Clarifications

None yet.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]