Release Process

Tickets

The cornerstone of the release process is our ticketing system. All bug fixes and new features are documented under a ticket. This allows a global community to identify, document, reproduce and fix issues.

For the Chef and Ohai projects we follow this process. It differs slightly for others:

1. Ticket is filed describing a bug or desired feature
2. Any further documentation detailing the reproduction of the bug is added
3. A discussion may occur on the mailing list
4. Someone provides a possible fix and the ticket is marked resolved/fixed
5. The ticket is reviewed in one of Opscode's weekly triage meetings. If the fix is accepted for merge, it is marked 'Triaged,' otherwise it may be reopened for further work or rejected for a technical reason that will be specified.
   1. The contributor is validated as an approved contributor
   2. The code is reviewed
6. If the fix includes code, on a regular merge pass against triaged tickets:
   1. Unit tests are run
   2. A merge is completed
   3. fixVersion is set to the version of Chef that this will be included in
   4. The ticket is closed

Contributing

For information on contributing, the process is fully described at How to Contribute.

Versioning

The projects follow a versioning process similar to that documented by Rubygems.

Versions are represented by a series of three integers separated by periods, representing major, minor and point releases respectively.

Chef and Ohai currently use the minor version to indicate changes that may include breaking changes, while other projects use the major version similar to other projects. These types of changes may include a change to the API that is not backward compatible, or a change in the default behavior of a provider.

• An even numbered point version represents an official published release.
• An odd numbered point release means that you're using a development version.
  (While this can help identify that you've installed a project from the source code, it is important to remember that two installations with the same development version may not actually be the same based in development changes having occurred during the time between which the two same numbered development versions were installed.)

If needed, beta and release candidates are indiciated by a suffix of '.beta.x' or '.rc.x' respectively, where x is an integer.

For example, if the last published release was 1.0.0 and the current development release is 1.0.1, we may release:

• 1.0.2.beta.1,
• 1.0.2.beta.2,
• 1.0.2.rc.1, then
• 1.0.2 (final).

This is used because Gems, which is our primary method of releasing the code, consider any version with a letter in it as a pre-release, allowing us to push it to rubygems.org for download, but ensuring it won't be installed accidentally without the use of the '--pre' gem command flag.