Skip to content

Version Strings

Jump to bottom
Kenyon Ralph edited this page Jan 3, 2017 · 4 revisions

Version strings are what is watermarked in the lower PNG part, or in every page footer.

Their layout has changed a little to cope with the multiple branching that git nicely enables.

Released versions

Official Tarballs

For our official tarballs, hosted at https://github.com/munin-monitoring/munin/releases, nothing has changed : it is still the same plain revision number.

Example : 2.0.1

Packaged versions

They are usually branded as the official release they are based off. Note that they can include quite a fair amount of back-ported patches, so you have to refer to the distro specific documentation.

master and stable-* branches

Here we just take the usual output of git describe.

It is either the plain revision number if nothing changed, or append to the latest revision number :

  • the number of commits since the latest release.
  • the -g string (as commit Git hash)
  • the first 7 hex chars of the last commit SHA1.

Example : 2.0.1-21-g2c15cad or 2.0.11-172-ga5f2c21

Rationale

They follows very closely a released version, so we would like to know which and how close they are.

Any other branch

It can be devel or a feature-based one such as my-new-feature.

Here we take, in order :

  • the version it is based off
  • the branch name
  • the date of the last commit.
  • the -c string (as commit Counter)
  • the number of commits since the latest release.
  • the -g string (as commit Git hash)
  • the first 7 hex chars of the last commit SHA1.

Examples : 2.0.9-devel-2012-12-31-c7-g7c6bb86 or 2.0.1-my-new-feature-2012-06-05-c10-g69a3159.

Rationale

Other branches do not closely follow a released version, but they are still based off one. Feature-based branches might take a long time to be merged, that is why there is a commit date instead of a number of commits. The number of commits is still present, to be able to order the version correctly as the SHA1 is obviously not ordered. It is near the end as we do not want bad interaction when rebasing and/or squashing heavily.

The SHA1 is only here to provide an immediate feedback on where the version was, without having to manually count the commits, or use git advanced resolution helper.

Note that it has not much meaning to compare 2 version strings from unrelated branches together.

Clone this wiki locally