7. Releases

7.1. Version Scheme

There are two named releases and many semantic versioned releases.

  • tip - This is the currently built master code. It follows the bleeding edge of the trees.
  • stable - This is the default release used by install. It follows to most recently released code.

The other releases follow the v<Major>.<Minor>.<Patch> format. e.g. v3.0.0

The Install process will default to stable but can be modified to use other releases.

Docs are also generated for these as well.

The full version string generated by the build tool looks like this:

  • v3.0.0-tip-galthaus-dev-19-d012b1d6ba892c96c81c24ee93b668591663ca5c
  • v3.0.0-tip-16-e1fa235dc28f7d278bc34a0d4db87c306d9d3ba8
  • v3.0.0-0-821108c416dfc1486919baa52dae284975d2ad8b

The base form is base semver tag, extra pieces, gits ahead of that base, and the actual git commit checksum.

The extra pieces is either -tip to indicate that the build comes from the tip of the tree or -tip-<username>-dev where the username is who built the custom build that is ahead of tip at the time.

The dr-provision server reports its version on start-up or can be queried by running:

dr-provision --version

The drpcli client reports its version by running:

drpcli version

7.2. Release Process

The team will regularly move the tip tag to track the leading edge of the master branch. This will make the resulting build available in the releases tab.

Additionally, as releases cut at stable points, the stable tag will be set to the new most recent milestone. Release notes and comments will be added to the github release page.

7.3. Release Notes

Each of the release specific changes are annotated in the Release Notes documentation. You can find the release notes at: