Skip to content

VersionNumbers

Jump to bottom
dpocock edited this page Mar 21, 2012 · 3 revisions

Background

  • 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).

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

Useful links

Clone this wiki locally