Re: Suggested even/odd convention for the micro version numbers (like cairo)

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Ter, 2007-12-11 at 10:37 +0200, Tor Lillqvist wrote:
> I humbly suggest that the versioning recommendation for the GTK+ stack
> and GNOME in general is amended for the third "micro" part of the
> version numbers to match the convention used in cairo.
> 
> See http://cairographics.org/manual/cairo-Version-Information.html .
> 
> In a nutshell, the idea is that released tarballs have an even micro
> version. The micro version is bumped both immediately before and after
> building the release tarball. The even micro number is never committed
> to SVN. In SVN the micro number is always odd.
> 
> This has the advantage that there is never any confusion whether
> pre-release or post-release bump is used. Code from a SVN checkout can
> always be recognised by its odd micro number, and correspondingly code
> from a released tarball is recognised by its even micro number.
> 
> One could imagine a module using a macro FOO_IS_DEVELOPMENT_VERSION()
> that would return true either if 1) the minor version is odd (as the
> convention already is in most (?) GNOME modules), or 2) the micro
> number is odd (a build from SVN, presumably thus intended for local
> hacking and not distribution).
> 
> I guess one disadvantage of this is that it might take a time before
> people stop asking "what happened to version x.y.z". Also, one
> probably needs to script the bump-make dist-bump sequence in order not
> to forget it, at least initially.
> 
> I think the use of this convention is regarded as a success by people
> working on cairo?

This sounds like a good idea.

Another idea that you may consider is what I came up with for a project
of mine (pybindgen), where the version is:
 - X.Y.Z, for stable releases;
 - X.Y.Z.W, for bzr snapshots, where X.Y.Z is the latest release before
the snapshot, and W is the bzr revision number.

For instance, at the release time the version may appear as 0.8.0, but
when I commit something after the release the bzr version appears as
something like 0.8.0.214.  Looking at 0.8.0.214 it becomes easy to see
that it is a bzr version which comes right after the official 0.8.0
release.

But, anyway, your idea is simpler to implement[1], and probably good
enough...

[1] although in my case the version numbering is derived automatically
by a hook: the 0.8.0 part comes from the nearest bzr tag, while the 214
is the current 'revno'.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert