Re: Suggested even/odd convention for the micro version numbers (like cairo)
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: Tor Lillqvist <tml iki fi>
- Cc: gtk-devel-list gnome org, desktop-devel-list gnome org
- Subject: Re: Suggested even/odd convention for the micro version numbers (like cairo)
- Date: Tue, 11 Dec 2007 11:09:26 +0000
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
But, anyway, your idea is simpler to implement, and probably good
 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
] [Thread Prev