...
Ensure that every feature is broken down into testable units and only testable units get checked in. This means that good set of unit test and system tests are written for sub tasks before they are checked in. This will ensure that trunk master is in a relatively stable state to release at any point of time.
Use feature branches. Create branches from trunk master that are focused on a specific feature. The feature developers ensure that the branch is in sync with trunk master from time to time. Once there is high level of confidence on the stability, it can be merged into trunkmaster. This approach has the additional overhead of branching and performing merges from time to time.
In practice, the right approach would be a mix of both ‘a’ and ‘b’. The feature developers need to make this call depending on the complexity of the feature.
What are the gaps that we need to focus on?
There are some gaps in the development process and testing infrastructure that we need to close to ensure that we can successfully do a time based release. This is going to be a long term effort but will simplify time based releases as we make more progress in closing them.
...
.
...
...
Compatibility testing for AK. We have system tests for verifying the behaviour of AK rolling upgrades. These tests help detect unexpected incompatible protocol and ZK structure changes, but they are not sufficient to ensure that an upgrade from an AK trunk commit to another AK trunk commit works correctly (LinkedIn reported one such bug just before 0.10.0.0 was released). In addition, we don't have anything that verifies API source/binary compatibility (flink-1880 includes a WIP PR for this). We would need to extend our suite of tests to provide the required coverage.
What Is Our EOL Policy?
Given 3 releases a year and the fact that no one upgrades three times a year, we propose making sure (by testing!) that rolling upgrade can be done from each release in the past year (i.e. last 3 releases) to the latest version.
We will also attempt, as a community to do bugfix releases as needed for the last 3 releases.
Who Manages The Releases?
As usual, a committer shall volunteer. If no committer volunteers, we'll cancel a release due to lack of interest.
What About Version Numbers?
Feature releases will be a minor release by default 0.10.1, 0.10.2 - unless:
...
.
...