[DISCUSS] NiFi support model and git processes

[Joe Witt <jo...@apache.org>]

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

Re: [DISCUSS] NiFi support model and git processes

[Joe Witt <jo...@gmail.com>]

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 <jo...@gmail.com> 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 <tr...@gmail.com> 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" <jo...@apache.org> 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
>>>

Re: [DISCUSS] NiFi support model and git processes

[Joe Witt <jo...@gmail.com>]

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 <tr...@gmail.com> 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" <jo...@apache.org> 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
>>

Re: [DISCUSS] NiFi support model and git processes

[Tony Kurc <tr...@gmail.com>]

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" <jo...@apache.org> 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
>