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
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]