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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
