Version 2! Re: [Nautilus-list] New Versioning Scheme

[Robin * Slomkowski <rslomkow eazel com>]

OK perhaps this is the second attempt at a versioning scheme.

There is a diagram at the bottom to help explain this once again,
as the diagram is more clear than I can put this into words.

I have added Elliots suggestion of standardizing cvs tags in the 
way many gnome projects do.

I have added Darin's request for a way to milestone development
releases.

I have ignored Maciej's suggestions, and kept the .cvs notion, because
it makes sorting easier, and it allow letter to be used in release
numbers.

We need labels for 5 different things.

1: a version in configure.in that is the released version of code.
2: a version in configure.in that is for development versions of code.
3: a source repository label for what code will be branched
4: a source repository label for branches
5: a source repository label for releases

We want the labels in the source repository to bear some resemblence
to the versions that users see.  We want development versions to
never to be mistaken for released versions.

(1) a version in configure.in that is the released version of code.

The version in configure.in should be a series of numbers that have
been seperated by '.'s  Each subsquent version should be higher than
the previous.  This is required for having sensible sorting for
maintaining packages.  So 0.2 can by followed by 0.5 which may be
followed by 0.28, but may not be followed by 0.7, Patch versions
should add additional tumbler should be added for patch version.  

So the patch to 0.2 would be 0.2.1, a patch for 5.1.2 would be 5.1.2.1

(2) a version in configure.in that is for development versions of code.

The version for development versions should always contain cvs in a
tumbler.  The version should follow the previous version, so if you 
had been working on 0.2 then 0.2.cvs be the version in the configure.in
for developers after the release of 0.2 on the main branch of
development.  If developers require and unreleased milestone that
would be 0.2.cvs.1, and that final number would increase as apropriate.

When on a branch to produce patch releases, the number for the patch
would be ahead of the cvs tumbler, so it would look like 0.2.0.cvs.
The patch release would be 0.2.1 and that would be contained only in
the released file, and from then on developers would work with a file
that said 0.2.1.cvs as the version.

FOR the next 3 sections I am using the standard gnome naming as
described by Elliot <sopwith redhat com>

(3) a source repository label for what code will be branched

The label will be the module name "_" Release version number with 
"." converted into "_", with the word "_ANCHOR" added to the end.
So for Nautilus 0.5 would become NAUTILUS_0_5_ANCHOR.  In this
example that configure.in that was so tagged would most likely contain
0.4.cvs as its version, and after the branching that would be changed
to 0.5.

(4) a source repository label for branches

In practice there should be a branch for all supported version of
the software, as minor bug fixes are a reality.  When we create these
branches they will be based off of the "ANCHOR" tag, and will
by named the module name "-" version number with the "." converted
to "-".  For example the branch for 0.5 for Nautilus would be 
nautilus-0-5.

(5) a source repository label for releases

When each release comes out there should be a tag in the repository 
to not that specific code.  When the software is tagged the
configure.in should match the release number.  The tag should be all
in upper case and "." should be converted to "_".  For example Nautilus
release 0.5.1 would be NAUTILUS_0_5_1.

--------------------------
Diagram of Version Control
--------------------------

  NAUTILUS_0_2_ANCHOR  NAUTILUS_0_3_ANCHOR
             |                  |
NAUTILUS_0_1 |                  |
     |       |                  |
    0.1    0.2.cvs            0.3.cvs
HEAD-||------|--------|---------|----------|----------|---->
      |      |     0.2.cvs.1    |      0.3.cvs.1   0.3.cvs.2
   0.1.cvs   |                  |      
             |                  | NAUTILUS_0_3
             |                  |      |
             |                  |     0.3    0.3.0.cvs
             |     nautilus-0-3 \------|-------|------>
             |
	     |NAUTILUS_0_2  NAUTILUS_0_2_1  NAUTILUS_0_2_2
	     | |             |               |
             \ 0.2          0.2.1          0.2.2    0.2.2.cvs
 nautilus-0-2 \|--------------|--------------|---------->

explenation of tags on diagram.

Label			Meaning
--------------------	------------------
HEAD			Leading Branch
0.1			the version in configure.in for release 0.1
NAUTILUS_0_1		The tag for release 0.1
0.1.cvs			the version in configure.in for development
			after 0.1, which in this case is 0.2
NAUTILUS_0_2_ANCHOR	A tag from which Branch 0.2 was created
nautilus-0-2		Branch for release 0.2 aka sticky tag
0.2.cvs			the version in configure.in for development
			post 0.2 and before 0.3
0.2			the version in configure.in
NAUTILUS_0_2		The tag for release 0.2
0.2.1			the version in configure.in for release 0.2.1
NAUTILUS_0_2_1		the tag for release 0.2.1
0.2.2			the version in configure.in for release 0.2.2
NAUTILUS_0_2_2		the tag for release 0.2.2
0.2.2.cvs		the version in configure.in for development
			after release 0.2.2 along the same branch
0.2.cvs.1		the version in configure.in for development
			after 0.2, before 0.3, that requires an 
			unreleased checkpoint.
NAUTILUS_0_3_ANCHOR	A tag from which Branch 0.3 was created
0.3.cvs			the version in configure.in for release 0.3
nautilus-0-3		Branch for release 0.3 aka sticky tag
NAUTILUS_0_3		The tag for the release of 0.3
0.3			the version in configure.in for release 0.3
0.3.cvs			the version in configure.in for development
			after 0.3 and before the next version.
0.3.cvs.1		the version in configure.in for development
			to show an unreleased milestone.
0.3.cvs.2		the version in configure.in for development
			to show the next unreleased mileston.
0.3.0.cvs		the version in configure.in for development
			of the next patch release on the nautilus-0-3
			branch.