agreed. There is already a 'mechanically inclined' thread anyway. So let's focus on:
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 On Tue, Feb 16, 2016 at 3:54 PM, Tony Kurc <[email protected]> wrote: > Joe, > You have a lot here, so what I recommend is taking the 'and git processes' > out of this discussion to avoid conflating the support model from how we > execute the suppler plan, order that state upfront "we should be able to > pull off whatever the support plan is in git". > > Tony > On Feb 16, 2016 2:14 PM, "Joe Witt" <[email protected]> wrote: > >> 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 >>
