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 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 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.
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.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 :
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.
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.
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.
None yet.
None yet.