Release Practices

When deploying this release, please consider the following in regards to the stability and compliance of your deployments.

Dependencies

This release contains several components from upstream projects. New versions are monitored and automatically integrated by CI. Where available, checksums and PGP verification are used to verify upstream artifacts.

You can find additional details about licenses of these components from the LICENSES file in the source repository along with references to the original artifacts and their source code.

Versioning

Releases are versioned according to semantic versioning rules…

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

When upstream dependencies change, their respective version bumps may not be surfaced by an equivalent version bump in this release. For example, if a dependency is upgraded from 2.3.4 to 2.4.0, the release version may only bump the patch if new features are not exposed through the release.

A forward-fixing versioning policy is followed. In general, fixes will not be backported.

Channels

When referencing this release, you should typically follow the stable channel which contains the official final release tarballs. Alternatively, you can find tarballs of this release on bosh.io.

If you prefer using development releases with potential bugs, the following channels are also available (from later to earlier in the testing process):

  • rc channel – testing in external environments has completed successfully
  • beta channel – testing within the scope of the repository’s CI has completed successfully
  • alpha channel – development builds without any completed, successful testing