-
Notifications
You must be signed in to change notification settings - Fork 245
VersionNumbers
dpocock edited this page Mar 21, 2012
·
3 revisions
- Source code:
- 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).
- 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
- 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