Team, Some recent discussions have indicated we are at the stage where we need to clarify both our support model and the git processes we will use to follow them. This is due to growth of the community, maturity of the release cycle, and that now we are at the stage where we need to begin our next major release line.
Proposed clarifications of our support model and git processes to follow it. Support Model: - We support the newest major release line (0.x, 1.x) and any previous major release lines up to one year since the last minor release (0.4.y, 1.5.y) in that line - When master has no releases we will backport any appropriate changes (fix, feature, enhancement) to the previous major release line - Any security or data loss related fixes should be back ported to all supported major release lines - Fixes, improvements, features will be applied to the next release (minor or incremental) within a given major release line and will only be back ported on a case by case basis for fixes - In order to consider a patch for back porting to a previous minor release line a request needs to be made to the developer or user mailing list with a successful discussion and a release candidate produced Git processes - We will have a branch for each major release line - The branch designated 'master' will be for the latest major release line under active development - Commits against master should be evaluated for whether they should be cherry-picked to other still supported major release lines consistent with the community support model - When a release occurs a signed tag will be generated and the version for that major line will be bumped to the next incremental release snapshot - The next commit on a given major release line that requires a minor version change should increment the minor version number and reset incremental to zero - Major version changes should only ever be prompted from the master branch and should only occur when a commit warrants changing the major version at which point a major release line branch should be created off of master for the previous major release line So, with that guidance in mind let's think about how that would work given our current status which is we will have Apache NIFi 0.5.0 released and we are ready to begin work on the 1.x line. The 1.x line will likely not have a release ready for some months but we will want to keep rolling ahead on the 0.x line with 0.6.0 being the next likely release. In this model then we would have master evolve as the 1.x line and any changes made there would be applied as mentioned above to the 0.6 and beyond releases on the 0.x line. Thanks Joe
