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

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 .
> 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  Looking at 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[1], and probably good

[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]