Discussion period is supposed to be over for GEP-4.. I've tried to integrate all comments in the attached draft (mainly about versioning proposed solution, since everything else seems ok). Feel free to comment (typo, etc...). And BTW, Michael, what should we do know ? :)) -- Frederic Crozat MandrakeSoftTitle: 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.
Why do we need guidelines for versioning, branching and tagging ?
During GNOME 2.0 release, several issues were raised such as :
Theses guidelines have been deduced from the encountered problems. They should not be seen as an inflexible and administrative policy 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.
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.
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.
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
This only applies to modules which doesn't have either own versioning system and whose previous versions are below X.Y
Z must follow the following rules :
When GNOME X.Y is released as final (or when module maintainer thinks developement finished for this module for X.Y timeframe) :
When a new version of the platform is released on X.Y branch (aka X.Y.Z), if new release need to be done on this module, Z is incremented and T reset to 0.
Summary :
Example for GNOME 2.2 development :
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 :
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.
Solution : versioning is no longer hardwired to platform version in this GEP requirements. It is only suggested as a work hypothesis in the proposed solution (which maintainers are free to follow or not).
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.
Solution : in new version of the proposal, this problem has been fixed. Micro-versioning is only used for stable release, modules don't need to be re-released if the only changes is version number.
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.
Solution : fixed in new draft of the proposal : maintainers are free to branch at feature freeze, when final release is done or even only when new developement is started.
None yet.
None yet.