Ganglia source code is maintained in git, which supports any arbitrary `tag' name, which is usually a version number, but the format of the tag name is not enforced or interpreted by git itself
Parts of Ganglia (e.g. web) are currently kept in separate git repositories (which have a different history of tags and version numbers that should be ignored)
Ganglia is compiled using the autotools framework, which supports a version number defined in configure.in (or configure.ac)
Packaging:
Ganglia is packaged on a number of platforms, each platform has different version number conventions:
RPM packages: RHEL/EPEL, Fedora, Centos, AIX
Deb packages: Debian, Ubuntu
SRV4 packages: Solaris OpenCSW
MSI packages: Windows
Some users build in-house packages using custom suffixes appended to the version number
Up to 3.1.7, each release also had a name (chosen from an aviation theme).
Objectives
Common version number conventions good for all packaging systems
Keep the release process simple
Provide flexibility for people to continue versioning their in-house builds
Detail
From past discussions on the subject, it has been agreed that:
each release candidate should have a version number in the format Major.Minor.Revision
after tagging, the release is not immediately advertised, it is made available in a `pre-release' download page.
It should be considered a release candidate for some period (maybe 7 days) while it is tested (e.g. test the tarball with rpmbuild, mgar)
after some testing, the same tarball is then moved to the official download page and advertised on the mailing lists
when it becomes official, the version number is not changed in any way, there is no new tag, etc (Ganglia does not build ganglia-3.1.7rc123.tar.gz, for example)
Git makes it easy to use tags, almost like bookmarks in the web browser
It has been proposed that developers can tag something that they intend to release, for example, the 3.3.3dp1 tag
Such tags are not intended for building supported binary packages
People can build binary packages and install them, but may have to force remove them before installing a later release
However, these tags can be used to give the community an opportunity to sanity check the tarball, which is quite useful when autotools stuff is changed