Some of the greatest assets of the Deis team are velocity and agility. Workflow changed rapidly and with relative ease during initial development.
Deis now harnesses those strengths into powering a regular, public release cadence. From v2.0.0 onward, the Deis team will release a minor version every 2 weeks, with patch versions as needed. The project will use GitHub milestones to communicate the content and timing of major and minor releases.
Deis releases are not feature-based, in that dates are not linked to specific features. If a feature is merged before the release date, it is included in the next minor or major release.
The master git branch of Deis should always work. Only changes considered ready to be released
publicly are merged, and non-patch releases are cut from master.
Deis releases comply with semantic versioning, with the "public API" broadly defined as:
- the REST API for the Controller
deisCLI commands and options
Users of Workflow can be confident that upgrading to a patch or to a minor release will not change the behavior of these items in a backward-incompatible way.
For any Workflow release to be made publicly available, it must meet at least these criteria:
- Passes all tests on the supported, load-balancing cloud providers
- Has no new regressions in behavior that are not considered trivial
A patch release of Workflow includes backwards-compatible bug fixes. Upgrading to this version is safe and can be done in-place.
Backwards-compatible bug fixes to Workflow are merged into the master branch at any time after they have two approval comments.
Patch releases are created as often as needed, based on the priority of one or more bug fixes that have been merged. If time or severity is crucial, an individual maintainer can create a patch release without consensus from others. Patch releases are created from a previous release by cherry-picking specific bug fixes from the master branch to the release branch, then applying and pushing the new release tag.
A minor release of Workflow introduces functionality in a backward-compatible manner. Upgrading to this version is safe and can be done in-place.
Backwards-compatible functionality changes to Workflow are merged into the master branch after they have two approval comments, and after the PR has been assigned to a milestone tracking the minor release.
It is preferable to merge several backwards-compatible functionality changes for a single minor release.
The Deis team will use GitHub milestones to communicate the content and timing of planned minor releases.
A minor release may be superceded by a major release.
A major release of Workflow introduces incompatible API changes. Custom integrations with Workflow may need to be updated.
Incompatible changes to Workflow are merged into the master branch deliberately, by agreement among maintainers. In addition to two approval comments, the pull request must be assigned to a planning milestone for that release, at which point it can be merged when release activities and testing begin.
The Deis team will use GitHub milestones to communicate the content and timing of planned major releases.