There appears to be little concern over the proposed support model as listed here
'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' I will go ahead and document this on a wiki soon. Will respond with the proposed git processes on Tony's thread. Thanks Joe On Tue, Feb 16, 2016 at 3:56 PM, Joe Witt <[email protected]> wrote: > 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 >>>
