GEP-4 : Versioning and branching rules proposal

[Frederic Crozat <fcrozat mandrakesoft com>]

Here is the announce for GEP-4 : versioning and branching rules for
GNOME modules..

Discussions should be done on desktop-devel list..
-- 
Frederic Crozat
MandrakeSoft

Title: REQUIREMENTS GEP 4: GNOME module versioning and branching rules

Rules module maintainers should follow when versioning, tagging or branching modules.

1. Administrivia

Document Owner

Frederic Crozat

Posted

August 30, 2002

Discussion Period Ends

September 27, 2002

Status

Pending

Discussion List

desktop-devel-list gnome org

Responsible Persons

Frederic Crozat, Havoc Pennington Nils Pedersen Michael Meeks Mark McLoughlin Seth Nickell Jacob Berkman

2. Proposal

Starting with GNOME 2.2 development,modules which are part of GNOME platform should be versioned using common rules described in section 2.1. To ease CVS access and maintainance, branching and tagging should follow rules in section 2.2.

2.1 Module versioning

To ease recognition by users, translators, vendors and any interested parties in GNOME development, the following rules should be used when GNOME platform modules are versioned :

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 developping X.Y version, snapshot releases should be versioned as X.(Y-1).Z.T.

Z and T must follow the following rules :

• each new beta release of the platform should should increment Z.
• for release candidate, Z should be superior or equal 90.
• between beta or candidate releases of the platform, T should be incremented for each release of the module, and each new increase in Z will reset T to 0.

Of course, each new release of a module should be strictly superior to previous releases of the same module, to ease upgrade.

When GNOME X.Y is released as final :

• modules should be released as X.Y.0 (ie Z = 0).
• Each new release of modules based on X.Y branch will be versioned as X.Y.0.T.

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 :

• before first beta of 2.2 is released, all modules should be versioned as 2.1.0.T
• when first beta of 2.2 is released, modules are versioned as 2.1.1.T
• when second beta of 2.2 is released, modules are versioned as 2.1.2.T
• ...
• when first release candidate of 2.2 is released, modules are versioned as 2.1.90.T
• when 2.2 (ie 2.2.0) is released as final, modules are released as 2.2.0.0
• in 2.2.0 lifetime, modules are released in 2.2.0.T range
• when 2.2.1 is released, modules are released in 2.2.1.T range

2.2 CVS branching and tagging

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

Hypothesis : GNOME X.Y is the target release.

• All development for X.Y release is done on HEAD branch.
• When development is done for X.Y (ie X.Y.0 is released), HEAD branch should be tagged as GNOME_X_Y_0_ANCHOR and gnome-X-Y should be created.
• All commits for X.Y.Z should be done on both gnome-X-Y AND HEAD branchs (to prevent regressions) and new developments/features (for GNOME X.Y+2) should only go on HEAD branch.

Example from GNOME 2.0 development :

• during GNOME 2.0 development, development was done on HEAD branch.
• when GNOME 2.0 was released, gnome-2-0 branch was created and GNOME 2.0.Z releases were based on this branch. New developments for GNOME 2.2 were done on HEAD branch.

3. Issues Raised During Discussion

None yet.

4. Decision and Rationale

None yet.

5. Amendments and Clarifications

None yet.