You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Tony Kurc <tk...@apache.org> on 2016/02/13 16:16:01 UTC
[DISCUSS] git branching model
All,
I wanted to renew a discussion about our git branching model. We posted a
proposed roadmap a while back [1]. For those familiar, there are some
pretty big features that are going to be awesome, but at the same time, may
make having an overlap of supported major versions likely more desirable
due to the magnitude of changes on the way. It seems as though our current
de facto branching model may make that challenging. My observation is that
although we discussed doing something like gitflow [2], we seem to "just be
really careful around with master around a release" and move on to the next
release (and do some things I think are ugly if we need a quick bugfix
release like 0.4.1).
Some things I think we're happy with now. 'master' being our eternal
branch, and comfortable with feature branches named after their jiras. Its
pretty evident from looking at contributors' forks on github when doing PR
reviews that it is a pretty well understood convention.
I think we can find a way to keep the above going and still support
multiple versions being developed at once.
I have some ideas, but in order to avoid polluting the discussion with what
is in my head, I figured I'd hold off on suggestions and let people mull it
over.
Specific questions:
How do we;
- have a 1.X in development (many months, many features, and we want people
trying early)
- have 0.X continue to live while that is happening for people who need it
for production
- have some features target both 0.X and 1.X
- have relevant bugfixes hit both 0.X and 1.X
- avoid the pain of the 0.4.1 release?
What will master look like while we're doing this?
What will we call our branches?
Who would integrate patches and PRs into multiple versions? Reviewer?
Submitter? Or would this be another ticket?
What project does this well and could be a model?
What questions did I forget to ask?
Should we decide to only have one version "supported" at a time to avoid
this?
1.
http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
2. http://nvie.com/posts/a-successful-git-branching-model/
Thank you for your input
Tony
Re: [DISCUSS] git branching model
Posted by Joe Witt <jo...@gmail.com>.
I still am no Git wizard so happy to be largely in listen mode on this
topic. My 'assumption' of what we'd do here is basically as Matt
mentions.
On Sat, Feb 13, 2016 at 12:35 PM, Matt Gilman <ma...@gmail.com> wrote:
> A couple thoughts...
>
> Push release branches. This would help avoid the confusion we had with the
> 0.5.0 release. It would be clear that bug fixes being made for the current
> release would need to be pushed to both master and the release branch. It
> would also allow master to continue receiving commits that will not be
> incorporated into the current release. Using branches (in addition to tags)
> would make it easier if multiple folks are committing bug fixes as was the
> case with 0.5.0. It may even make sense to keep the release branch around
> for awhile (maybe X subsequent releases). This would also provide a
> convenient place to branch from if we needed a quick bugfix release like we
> did in 0.4.1.
>
> Moving forward when we start working some 1.X features I would like to see
> essentially two masters (though we can name them whatever we want).
> Continue with the same model (RTC) as we do currently but pushing commits
> to either the 0.X master, the 1.X master, or both. We would continue to
> support both master branches until we've stopped support for the 0.X
> baseline whenever we decide that will be.
>
> Matt
>
> On Sat, Feb 13, 2016 at 10:16 AM, Tony Kurc <tk...@apache.org> wrote:
>
>> All,
>> I wanted to renew a discussion about our git branching model. We posted a
>> proposed roadmap a while back [1]. For those familiar, there are some
>> pretty big features that are going to be awesome, but at the same time, may
>> make having an overlap of supported major versions likely more desirable
>> due to the magnitude of changes on the way. It seems as though our current
>> de facto branching model may make that challenging. My observation is that
>> although we discussed doing something like gitflow [2], we seem to "just be
>> really careful around with master around a release" and move on to the next
>> release (and do some things I think are ugly if we need a quick bugfix
>> release like 0.4.1).
>>
>> Some things I think we're happy with now. 'master' being our eternal
>> branch, and comfortable with feature branches named after their jiras. Its
>> pretty evident from looking at contributors' forks on github when doing PR
>> reviews that it is a pretty well understood convention.
>>
>> I think we can find a way to keep the above going and still support
>> multiple versions being developed at once.
>>
>> I have some ideas, but in order to avoid polluting the discussion with what
>> is in my head, I figured I'd hold off on suggestions and let people mull it
>> over.
>>
>> Specific questions:
>> How do we;
>> - have a 1.X in development (many months, many features, and we want people
>> trying early)
>> - have 0.X continue to live while that is happening for people who need it
>> for production
>> - have some features target both 0.X and 1.X
>> - have relevant bugfixes hit both 0.X and 1.X
>> - avoid the pain of the 0.4.1 release?
>>
>> What will master look like while we're doing this?
>> What will we call our branches?
>> Who would integrate patches and PRs into multiple versions? Reviewer?
>> Submitter? Or would this be another ticket?
>> What project does this well and could be a model?
>> What questions did I forget to ask?
>> Should we decide to only have one version "supported" at a time to avoid
>> this?
>>
>> 1.
>>
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>> 2. http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Thank you for your input
>>
>> Tony
>>
Re: [DISCUSS] git branching model
Posted by Matthew Burgess <ma...@gmail.com>.
The release branch approach (at least happy path) is IMHO the way to go. I’d just like to address from personal experience those times when commits don’t cherry-pick over. Do we put the onus on the developer to push PRs for the intended branches? In either case I would think the original patch/PR would go against master, then whomever is tasked with getting it back to the appropriate branches needs to do the cherry-pick (or whatever is the prudent way to apply the change) and get it into “past” branches. At my last place, the onus was on the developer to introduce the PR for master and a PR for every previous branch he/she would like to get the fix/feature into, and approval was given based on branch and community approval. Working backwards in time like this reduces regressions and forces a per-PR look at the commit in the appropriate context.
Regards,
Matt
On 2/13/16, 9:26 PM, "Joe Skora" <js...@gmail.com> wrote:
>+1 for a branching model with master as current dev, release branches for
>release development and fixes, and tags for marking release points.
>>
>> ** What will we call our branches?*
>> -> development (current the master)
>> -> v0.x-stable
>> -> v1.x-stable
>> -> v2.x-stable (v0.x-stable is deleted)
>> -> v3.x-stable (v1.x-stable is deleted)
>> Each branch would have multiple tags marking the minor releases.
>
>
>In general I don't care what the dev branch is called, but in my
>experience, Git-life is easier when master is the branch where development
>occurs.
>
>On Sat, Feb 13, 2016 at 8:44 PM, Andre <an...@fucs.org> wrote:
>
>> I am not a git specialist but I can share my view as a user:
>>
>> ** What will master look like while we're doing this?*
>> I've noticed depending on the project a master branch can be a stable
>> branch or a development branch and as long the behaviour of the branches is
>> clearly documented, the approach used is secondary. (except on golang
>> project where rules apply).
>>
>> ** What will we call our branches?*
>>
>> -> development (current the master)
>> -> v0.x-stable
>> -> v1.x-stable
>> -> v2.x-stable (v0.x-stable is deleted)
>> -> v3.x-stable (v1.x-stable is deleted)
>>
>> Each branch would have multiple tags marking the minor releases.
>>
>> Ditching master as a name will clearly state the intent of the branch and
>> allow the user / developer to know that by running on that version you are
>> from cutting edge.
>>
>> Having said that I suspect there are some minor issues about getting a git
>> without master to run on github [1]but given the project uses the ASF bot
>> and github replication it may worth checking if this is possible.
>>
>> Independently of the name master would be cutting edge and things could
>> break.
>>
>> ** Who would integrate patches and PRs into multiple versions?
>> Reviewer? Submitter? Or would this be another ticket?*
>>
>> If it is a new feature (e.g. new listener) it should be up to the submitter
>> to decide if support would be extended to currently stable release or would
>> reside just on the development branch.
>>
>> The key IMHO aren't the features but changes to shared code; as long we
>> prevent changes to existing classes and method signatures I think we would
>> be following the right track.
>>
>> It should be paramount to provide stability to code crafted outside the
>> project (a perfect example being NATS messaging processor that was never
>> merged into the project [2]) without hindering development of the product
>> within minor releases.
>>
>> Regarding bug fixes, I think anyone would be welcome to submit a fix to any
>> of the supported branches.
>>
>> ** What project does this well and could be a model?*
>>
>> I think a good model to look at is the one adopted by rsyslog project.
>>
>> If I'm not mistaken they adopt a release branch model.
>>
>> v7.x is no longer improved but still available for bug fix backport into
>> minor releases (controlled via tags).
>> v8.x stable is there and has tags for each of the minor releases.
>> master is the development tree
>>
>> ** Should we decide to only have one version "supported" at a time to
>> avoid this?*
>>
>> I reckon that nowadays the minimum expected by user base is major - 1 as
>> this prevents the requirement to adopt rolling releases.
>>
>> Also, by supported I mean security fixes and critical issues that may lead
>> to data loss and system crashes. features, nice to haves and other things
>> are up to a number of factors and I may or may not get them backported.
>>
>> Those who have ever dealt with RHEL know that you may ask RH to backport
>> feature blah to "version - 1"... you may ask, but truth is that sometimes
>> you will get it, sometimes you won't.
>>
>> Cheers
>>
>>
>> [1] https://matthew-brett.github.io/pydagogue/gh_delete_master.html
>> [2] https://github.com/mring33621/nats-messaging-for-nifi
>>
Re: [DISCUSS] git branching model
Posted by Joe Skora <js...@gmail.com>.
+1 for a branching model with master as current dev, release branches for
release development and fixes, and tags for marking release points.
>
> ** What will we call our branches?*
> -> development (current the master)
> -> v0.x-stable
> -> v1.x-stable
> -> v2.x-stable (v0.x-stable is deleted)
> -> v3.x-stable (v1.x-stable is deleted)
> Each branch would have multiple tags marking the minor releases.
In general I don't care what the dev branch is called, but in my
experience, Git-life is easier when master is the branch where development
occurs.
On Sat, Feb 13, 2016 at 8:44 PM, Andre <an...@fucs.org> wrote:
> I am not a git specialist but I can share my view as a user:
>
> ** What will master look like while we're doing this?*
> I've noticed depending on the project a master branch can be a stable
> branch or a development branch and as long the behaviour of the branches is
> clearly documented, the approach used is secondary. (except on golang
> project where rules apply).
>
> ** What will we call our branches?*
>
> -> development (current the master)
> -> v0.x-stable
> -> v1.x-stable
> -> v2.x-stable (v0.x-stable is deleted)
> -> v3.x-stable (v1.x-stable is deleted)
>
> Each branch would have multiple tags marking the minor releases.
>
> Ditching master as a name will clearly state the intent of the branch and
> allow the user / developer to know that by running on that version you are
> from cutting edge.
>
> Having said that I suspect there are some minor issues about getting a git
> without master to run on github [1]but given the project uses the ASF bot
> and github replication it may worth checking if this is possible.
>
> Independently of the name master would be cutting edge and things could
> break.
>
> ** Who would integrate patches and PRs into multiple versions?
> Reviewer? Submitter? Or would this be another ticket?*
>
> If it is a new feature (e.g. new listener) it should be up to the submitter
> to decide if support would be extended to currently stable release or would
> reside just on the development branch.
>
> The key IMHO aren't the features but changes to shared code; as long we
> prevent changes to existing classes and method signatures I think we would
> be following the right track.
>
> It should be paramount to provide stability to code crafted outside the
> project (a perfect example being NATS messaging processor that was never
> merged into the project [2]) without hindering development of the product
> within minor releases.
>
> Regarding bug fixes, I think anyone would be welcome to submit a fix to any
> of the supported branches.
>
> ** What project does this well and could be a model?*
>
> I think a good model to look at is the one adopted by rsyslog project.
>
> If I'm not mistaken they adopt a release branch model.
>
> v7.x is no longer improved but still available for bug fix backport into
> minor releases (controlled via tags).
> v8.x stable is there and has tags for each of the minor releases.
> master is the development tree
>
> ** Should we decide to only have one version "supported" at a time to
> avoid this?*
>
> I reckon that nowadays the minimum expected by user base is major - 1 as
> this prevents the requirement to adopt rolling releases.
>
> Also, by supported I mean security fixes and critical issues that may lead
> to data loss and system crashes. features, nice to haves and other things
> are up to a number of factors and I may or may not get them backported.
>
> Those who have ever dealt with RHEL know that you may ask RH to backport
> feature blah to "version - 1"... you may ask, but truth is that sometimes
> you will get it, sometimes you won't.
>
> Cheers
>
>
> [1] https://matthew-brett.github.io/pydagogue/gh_delete_master.html
> [2] https://github.com/mring33621/nats-messaging-for-nifi
>
Re: [DISCUSS] git branching model
Posted by Andre <an...@fucs.org>.
I am not a git specialist but I can share my view as a user:
** What will master look like while we're doing this?*
I've noticed depending on the project a master branch can be a stable
branch or a development branch and as long the behaviour of the branches is
clearly documented, the approach used is secondary. (except on golang
project where rules apply).
** What will we call our branches?*
-> development (current the master)
-> v0.x-stable
-> v1.x-stable
-> v2.x-stable (v0.x-stable is deleted)
-> v3.x-stable (v1.x-stable is deleted)
Each branch would have multiple tags marking the minor releases.
Ditching master as a name will clearly state the intent of the branch and
allow the user / developer to know that by running on that version you are
from cutting edge.
Having said that I suspect there are some minor issues about getting a git
without master to run on github [1]but given the project uses the ASF bot
and github replication it may worth checking if this is possible.
Independently of the name master would be cutting edge and things could
break.
** Who would integrate patches and PRs into multiple versions?
Reviewer? Submitter? Or would this be another ticket?*
If it is a new feature (e.g. new listener) it should be up to the submitter
to decide if support would be extended to currently stable release or would
reside just on the development branch.
The key IMHO aren't the features but changes to shared code; as long we
prevent changes to existing classes and method signatures I think we would
be following the right track.
It should be paramount to provide stability to code crafted outside the
project (a perfect example being NATS messaging processor that was never
merged into the project [2]) without hindering development of the product
within minor releases.
Regarding bug fixes, I think anyone would be welcome to submit a fix to any
of the supported branches.
** What project does this well and could be a model?*
I think a good model to look at is the one adopted by rsyslog project.
If I'm not mistaken they adopt a release branch model.
v7.x is no longer improved but still available for bug fix backport into
minor releases (controlled via tags).
v8.x stable is there and has tags for each of the minor releases.
master is the development tree
** Should we decide to only have one version "supported" at a time to
avoid this?*
I reckon that nowadays the minimum expected by user base is major - 1 as
this prevents the requirement to adopt rolling releases.
Also, by supported I mean security fixes and critical issues that may lead
to data loss and system crashes. features, nice to haves and other things
are up to a number of factors and I may or may not get them backported.
Those who have ever dealt with RHEL know that you may ask RH to backport
feature blah to "version - 1"... you may ask, but truth is that sometimes
you will get it, sometimes you won't.
Cheers
[1] https://matthew-brett.github.io/pydagogue/gh_delete_master.html
[2] https://github.com/mring33621/nats-messaging-for-nifi
Re: [DISCUSS] git branching model
Posted by Sean Busbey <bu...@apache.org>.
On Mon, Apr 4, 2016 at 1:39 PM, Tony Kurc <tr...@gmail.com> wrote:
> Sean, how about yetus? Is this something yetus can do with the patch
> testing in an automated way?
Right now Yetus only checks a single target branch.
For commits that can apply/merge cleanly we could add something to
check multiple branches. I'd expect this would be a non-trivial
feature addition, esp since personalities would have to pick
strategies (cherry pick to list of branches, vs attempt
merge-forward). We could start with the former since it's probably
simpler.
Mind filing a JIRA so we don't lose track of the feature request?
If anyone in the NiFi community would like to grow how much they
understand bash and implementer would be a nice bonus. :)
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
Sean, how about yetus? Is this something yetus can do with the patch
testing in an automated way?
On Apr 4, 2016 1:14 PM, "Sean Busbey" <bu...@apache.org> wrote:
> You're correct, a github PR only targets a single branch and Travis-CI
> only checks how the PR does at its own commit hash (that is, it
> doesn't even check what the target branch would look like post-merge).
>
> On Mon, Apr 4, 2016 at 12:05 PM, Matt Gilman <ma...@gmail.com>
> wrote:
> > To my knowledge, when you open a PR in GitHub it only allows the
> > contributor to select a single branch. The reviewer would need to check
> the
> > compatibility if that contribution needs to be applied to both. Depending
> > on the contribution, a separate PR may be required as the codebases
> > diverge. In practice though, most of the work on master (1.x) will focus
> on
> > the framework which is where diverging is most likely to occur.
> > Consequently, framework bug fixes are the most likely place where we may
> > need separate PRs.
> >
> > On Mon, Apr 4, 2016 at 12:46 PM, Tony Kurc <tr...@gmail.com> wrote:
> >
> >> Is travis ci / githib able to give immediate feedback if a PR doesn't
> merge
> >> into both?
> >>
> >> On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman <ma...@gmail.com>
> >> wrote:
> >>
> >> > All,
> >> >
> >> > I have completed the branching discussed last week.
> >> >
> >> > - master contains the current 1.x baseline - Future 1.x releases will
> >> start
> >> > from here
> >> > - 0.x contains the 0.x baseline - Future 0.x releases will start from
> >> here
> >> >
> >> > Going forward all PRs will need to be merged the either or both
> branches
> >> as
> >> > appropriate to ensure it's included in subsequent releases. I will be
> >> > updating the quick start and contributor guide to describe the
> >> distinction
> >> > between the two branches.
> >> >
> >> > Thanks!
> >> >
> >> > Matt
> >> >
> >> > On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <matt.c.gilman@gmail.com
> >
> >> > wrote:
> >> >
> >> > > The majority consensus is to have master point to our 1.x baseline
> >> going
> >> > > forward. Unless there are any strong objections I will set
> everything
> >> up
> >> > on
> >> > > Monday (4/4) morning.
> >> > >
> >> > > - Create a 0.x branch for all future 0.x releases based on the
> current
> >> > > state of master.
> >> > > - Apply all 1.x commits from the temporary 1.x branch to master.
> >> > > - Delete the temporary 1.x branch.
> >> > > - Update the quickstart page and contribution guide to detail the
> >> > > distinction between the 0.x and master branches.
> >> > > - Send another email to @dev once this has been completed.
> >> > >
> >> > > Reminder: Going forward once this has been completed all commits
> will
> >> > need
> >> > > to be made to both branches as appropriate.
> >> > >
> >> > > Thanks!
> >> > >
> >> > > Matt
> >> > >
> >> > > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <
> matt.c.gilman@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> Matt,
> >> > >>
> >> > >> I agree that the PRs would need to be merged to both baselines at
> >> > >> contribution time. If the contribution applies cleanly the reviewer
> >> > could
> >> > >> certainly handle the commit themselves. However, if additional code
> >> > changes
> >> > >> are required because the baselines have diverged, the contributor
> >> would
> >> > >> probably need to submit another PR. This additional effort should
> only
> >> > be
> >> > >> necessary until we're able to perform the first 1.x release.
> >> > >>
> >> > >> Aldrin,
> >> > >>
> >> > >> I definitely understand your thoughts regarding (1) and (2). This
> is
> >> why
> >> > >> I wanted to pose the options before just jumping into one approach
> vs
> >> > the
> >> > >> other. I personally prefer the GitHub style PR process. I realize
> this
> >> > is
> >> > >> more cumbersome but hopefully the number of conflicts should be
> small
> >> as
> >> > >> folks are already starting to focus their efforts on the framework
> for
> >> > 1.x.
> >> > >>
> >> > >> Matt
> >> > >>
> >> > >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <
> aldrinpiri@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >>> I think I prefer option 2 considering, what may be the incorrect
> >> > >>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be
> >> > easier.
> >> > >>> Based on outstanding PRs/Patches in conjunction with release
> cadence
> >> > >>> there
> >> > >>> will be more 0.x releases planned. Until we reached the point
> where
> >> the
> >> > >>> first 1.x release is in sight, I think (2) makes sense just from
> >> > >>> minimizing
> >> > >>> impedance where the majority of effort will occur (new/updated
> >> > >>> extensions)
> >> > >>> and then switching to (1) when we are scheduling 1.x as next
> >> (exclusive
> >> > >>> of
> >> > >>> any patch builds). This seems to work out when I try to reason
> about
> >> > it,
> >> > >>> but admittedly, am coming at this heavily from my own anecdotal
> >> > >>> perspective
> >> > >>> given my flow of reviewing.
> >> > >>>
> >> > >>> Matt, excellent points to consider.
> >> > >>>
> >> > >>> Do not want to go too much on a tangent from the current
> >> conversation,
> >> > >>> but
> >> > >>> I think we need to harness automation as much as possible. Not
> sure
> >> > >>> Travis
> >> > >>> can do this or do so easily (short of two PRs) and this may
> arguably
> >> > >>> shift
> >> > >>> things in favor of patches and the model that the other ASF
> projects
> >> > >>> utilize with buildbot. Getting as much done asynchronously for
> us is
> >> > >>> obviously important but we also have to strive to avoid a contrib
> >> > process
> >> > >>> that is too cumbersome as well.
> >> > >>>
> >> > >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <
> mattyb149@gmail.com>
> >> > >>> wrote:
> >> > >>>
> >> > >>> > I like option 1 as well.
> >> > >>> >
> >> > >>> > In the case where a fix is to be put into both branches, will
> the
> >> > >>> developer
> >> > >>> > be responsible for issuing 2 PRs / patches, one against each
> >> branch?
> >> > >>> This
> >> > >>> > would help in the case that the PR/patch against 0.x won't merge
> >> > >>> cleanly
> >> > >>> > into master; however the reviewer(s) would need to make sure
> there
> >> > >>> were no
> >> > >>> > breaking changes as a result of the manual merge to master. An
> >> > >>> alternative
> >> > >>> > is that the reviewer(s) do the forward-port, which I don't think
> >> is a
> >> > >>> good
> >> > >>> > idea. However the reviewer would need to make sure the PR(s) are
> >> > >>> against
> >> > >>> > the correct branch. For example, all current PRs would need to
> be
> >> > >>> > "backported" to the new 0.x branch.
> >> > >>> >
> >> > >>> > Also, I would think the PRs/patches need to be merged at the
> same
> >> > time
> >> > >>> (or
> >> > >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but
> >> > getting
> >> > >>> > forgotten/missed for 1.x).
> >> > >>> >
> >> > >>> > Thoughts? Thanks,
> >> > >>> > Matt
> >> > >>> >
> >> > >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com>
> >> > wrote:
> >> > >>> >
> >> > >>> > > I too prefer option 1
> >> > >>> > >
> >> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <brd@jhu.edu
> >
> >> > >>> wrote:
> >> > >>> > > > I agree with Tony on option 1. I think it makes sense for
> >> > master
> >> > >>> to
> >> > >>> > be
> >> > >>> > > > the most "advanced" branch. New features will then always
> be
> >> > >>> applied
> >> > >>> > to
> >> > >>> > > > master, and optionally to other branches for older version
> >> > support
> >> > >>> as
> >> > >>> > > > applicable / desired.
> >> > >>> > > >
> >> > >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <
> trkurc@gmail.com>
> >> > >>> wrote:
> >> > >>> > > >
> >> > >>> > > >> I like option 1
> >> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <
> >> > matt.c.gilman@gmail.com>
> >> > >>> > > wrote:
> >> > >>> > > >>
> >> > >>> > > >> > Hello,
> >> > >>> > > >> >
> >> > >>> > > >> > With NiFi 0.6.0 officially released and our support
> strategy
> >> > >>> defined
> >> > >>> > > [1],
> >> > >>> > > >> > I'd like to revisit and propose some options for
> supporting
> >> > >>> both a
> >> > >>> > 1.x
> >> > >>> > > >> > branch and 0.x branch concurrently. We need an official
> >> place
> >> > >>> where
> >> > >>> > > these
> >> > >>> > > >> > efforts can be worked, contributed to, and collaborated
> with
> >> > the
> >> > >>> > > >> community.
> >> > >>> > > >> > I've already created a 1.x branch as a temporary place
> for
> >> > this
> >> > >>> > > codebase
> >> > >>> > > >> to
> >> > >>> > > >> > live until we agree to an approach.
> >> > >>> > > >> >
> >> > >>> > > >> > Either option I'm proposing will require
> >> > >>> PRs/contributions/patches
> >> > >>> > to
> >> > >>> > > be
> >> > >>> > > >> > applied to both branches as applicable. This means that
> the
> >> > >>> > > contributor
> >> > >>> > > >> or
> >> > >>> > > >> > the reviewer will need to be able to apply the commits in
> >> both
> >> > >>> > places
> >> > >>> > > if
> >> > >>> > > >> > it's necessary. For instance, framework code has already
> >> > started
> >> > >>> > > >> diverging
> >> > >>> > > >> > from the current master so any framework change may not
> need
> >> > to
> >> > >>> be
> >> > >>> > > >> applied
> >> > >>> > > >> > to both if the changeset is not applicable to the 1.x
> >> > baseline.
> >> > >>> > > >> >
> >> > >>> > > >> > The only question at the moment is what master will refer
> >> to.
> >> > >>> > > >> >
> >> > >>> > > >> > 1) Create a branch for 0.x and allow master to become the
> >> 1.x
> >> > >>> > baseline
> >> > >>> > > >> > going forward. Future 0.x releases will be performed from
> >> the
> >> > >>> 0.x
> >> > >>> > > branch.
> >> > >>> > > >> > 2) Continuing working on the 1.x branch as is. Allow
> master
> >> to
> >> > >>> > > continue
> >> > >>> > > >> to
> >> > >>> > > >> > servicing 0.x releases. Once a 1.x release is made,
> create
> >> the
> >> > >>> 0.x
> >> > >>> > > branch
> >> > >>> > > >> > and then allow master to service 1.x releases.
> >> > >>> > > >> >
> >> > >>> > > >> > In short, when do we want master to point to the 1.x
> >> baseline?
> >> > >>> When
> >> > >>> > > >> should
> >> > >>> > > >> > we create a branch where 0.x releases will be made from.
> >> > >>> Regardless,
> >> > >>> > > >> > contributions will need to be performed to both places as
> >> > >>> > applicable.
> >> > >>> > > >> >
> >> > >>> > > >> > Thanks.
> >> > >>> > > >> >
> >> > >>> > > >> > Matt
> >> > >>> > > >> >
> >> > >>> > > >> > [1]
> >> > >>> > > >> >
> >> > >>> > > >> >
> >> > >>> > > >>
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >> > >>> > > >> >
> >> > >>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> >> > >>> > > r.p.miskin@gmail.com>
> >> > >>> > > >> > wrote:
> >> > >>> > > >> >
> >> > >>> > > >> > > I guess it will depend how much change is expected on
> the
> >> > >>> > > maintenance
> >> > >>> > > >> > > branches,
> >> > >>> > > >> > > but if you want every change in the maintenance branch
> to
> >> go
> >> > >>> into
> >> > >>> > > the
> >> > >>> > > >> > > main-line branch then there is little difference from a
> >> > >>> conflict
> >> > >>> > > point
> >> > >>> > > >> of
> >> > >>> > > >> > > view
> >> > >>> > > >> > > between a series of cherry-picks and a merge.
> >> > >>> > > >> > >
> >> > >>> > > >> > > Either way, it is just another approach to consider.
> >> There’s
> >> > >>> more
> >> > >>> > > than
> >> > >>> > > >> > one
> >> > >>> > > >> > > way to do it, and I suspect there isn’t any solution
> that
> >> > >>> makes it
> >> > >>> > > >> > trivial.
> >> > >>> > > >> > >
> >> > >>> > > >> > > Cheers,
> >> > >>> > > >> > > Richard
> >> > >>> > > >> > >
> >> > >>> > > >> > >
> >> > >>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <
> >> > aldrinpiri@gmail.com
> >> > >>> >
> >> > >>> > > wrote:
> >> > >>> > > >> > > >
> >> > >>> > > >> > > > On board with Tony's points. I think the realities
> of
> >> > >>> merging
> >> > >>> > in
> >> > >>> > > >> > > practice
> >> > >>> > > >> > > > when that "breaking point" of sorts occurs will make
> the
> >> > >>> > > complexity
> >> > >>> > > >> and
> >> > >>> > > >> > > > overhead quite difficult and maybe even more error
> prone
> >> > >>> than
> >> > >>> > the
> >> > >>> > > >> > cherry
> >> > >>> > > >> > > > picking approach with some additional guidelines.
> When
> >> > the
> >> > >>> > > codebase
> >> > >>> > > >> > > > drastically changes, the merge conflicts could be
> quite
> >> > >>> severe
> >> > >>> > and
> >> > >>> > > >> > > without
> >> > >>> > > >> > > > a good knowledge of each part of the codebase
> involved
> >> > >>> during
> >> > >>> > that
> >> > >>> > > >> > > process,
> >> > >>> > > >> > > > a committer may introduce regressions.
> >> > >>> > > >> > > >
> >> > >>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <
> >> > >>> trkurc@gmail.com>
> >> > >>> > > wrote:
> >> > >>> > > >> > > >
> >> > >>> > > >> > > >> the reason I like applying patches to both lines is
> >> that
> >> > >>> once
> >> > >>> > > code
> >> > >>> > > >> > > begins
> >> > >>> > > >> > > >> to diverge, cleanly merging into one codebase can be
> >> > >>> > impossible.
> >> > >>> > > >> > having
> >> > >>> > > >> > > >> good practices for managing patches and where they
> >> apply
> >> > is
> >> > >>> > > >> paramount
> >> > >>> > > >> > > for
> >> > >>> > > >> > > >> success.
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >> I expect that divergence to happen with 1.x. I
> wanted
> >> to
> >> > >>> get
> >> > >>> > in a
> >> > >>> > > >> > battle
> >> > >>> > > >> > > >> rhythm of sorts of managing multiple lines, even if
> the
> >> > >>> patches
> >> > >>> > > >> COULD
> >> > >>> > > >> > be
> >> > >>> > > >> > > >> applied to both in the manner you described.
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure
> that
> >> > >>> tickets
> >> > >>> > > >> marked
> >> > >>> > > >> > > for
> >> > >>> > > >> > > >> 0.5.1 had the right patches in the support branch,
> and
> >> > some
> >> > >>> > > didn't,
> >> > >>> > > >> > so I
> >> > >>> > > >> > > >> think "lesson learned". I do like in the apache
> >> > >>> infrastructure
> >> > >>> > > that
> >> > >>> > > >> if
> >> > >>> > > >> > > >> commits have the appropriate ticket in their commit
> >> > >>> message,
> >> > >>> > the
> >> > >>> > > >> jira
> >> > >>> > > >> > > will
> >> > >>> > > >> > > >> have the list of commits and branches those commits
> >> were
> >> > >>> > applies
> >> > >>> > > to.
> >> > >>> > > >> > > >> However, I think we may need to revisit commit
> message
> >> > >>> > > "hygiene" if
> >> > >>> > > >> > we
> >> > >>> > > >> > > >> relied on this instead of more manual review.
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> >> > >>> > > >> r.p.miskin@gmail.com
> >> > >>> > > >> > >
> >> > >>> > > >> > > >> wrote:
> >> > >>> > > >> > > >>
> >> > >>> > > >> > > >>> Hi,
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>> On a couple of work projects we found that the
> >> approach
> >> > of
> >> > >>> > > >> > > cherry-picking
> >> > >>> > > >> > > >>> commits can lead to an unnecessarily complicated
> >> history
> >> > >>> where
> >> > >>> > > the
> >> > >>> > > >> > same
> >> > >>> > > >> > > >>> piece of work appears as multiple separate commits
> on
> >> > >>> > different
> >> > >>> > > >> > > branches.
> >> > >>> > > >> > > >>> This can then make it hard to be confident that a
> bug
> >> > fix
> >> > >>> has
> >> > >>> > > been
> >> > >>> > > >> > > >> applied
> >> > >>> > > >> > > >>> to all relevant branches. We found that it works
> >> better
> >> > >>> to aim
> >> > >>> > > to
> >> > >>> > > >> > > commit
> >> > >>> > > >> > > >>> changes to the lowest applicable branch, and then
> >> > >>> regularly
> >> > >>> > > merge
> >> > >>> > > >> > those
> >> > >>> > > >> > > >>> branches to master. This approach is based on the
> >> > git-flow
> >> > >>> > > model (
> >> > >>> > > >> > > >>>
> >> http://nvie.com/posts/a-successful-git-branching-model/
> >> > <
> >> > >>> > > >> > > >>>
> >> http://nvie.com/posts/a-successful-git-branching-model/
> >> > >>> >).
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>> Looking at the repo there are already a few commits
> >> that
> >> > >>> are
> >> > >>> > > >> > duplicated
> >> > >>> > > >> > > >> on
> >> > >>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d
> >> only
> >> > >>> occur
> >> > >>> > on
> >> > >>> > > >> > 0.5.1,
> >> > >>> > > >> > > >> and
> >> > >>> > > >> > > >>> then that branch would get merged to master.
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>> Having the merge commits from the support branch to
> >> > master
> >> > >>> > > makes it
> >> > >>> > > >> > > >>> explicit in the git history that all bug fixes (and
> >> > >>> associated
> >> > >>> > > >> tests)
> >> > >>> > > >> > > >> have
> >> > >>> > > >> > > >>> been pulled through to master.
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>> Cheers,
> >> > >>> > > >> > > >>> Richard
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <
> >> jvwing@gmail.com
> >> > >
> >> > >>> > wrote:
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those
> and
> >> > >>> see if
> >> > >>> > > you
> >> > >>> > > >> > > agree:
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> 1.) Commits merged to master today are destined
> for
> >> the
> >> > >>> next
> >> > >>> > > minor
> >> > >>> > > >> > > >>> release,
> >> > >>> > > >> > > >>>> currently 0.6.0, by default?
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> By default, commits to master will be released in
> the
> >> > >>> next
> >> > >>> > > major
> >> > >>> > > >> or
> >> > >>> > > >> > > >> minor
> >> > >>> > > >> > > >>>> release. No commits are included in
> >> incremental/patch
> >> > >>> > > releases by
> >> > >>> > > >> > > >>> default.
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> support/0.5.x will be maintained until the first
> of
> >> the
> >> > >>> > > following
> >> > >>> > > >> > > >> events:
> >> > >>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major
> >> > >>> release
> >> > >>> > > line)
> >> > >>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous
> major
> >> > >>> release
> >> > >>> > > >> lines
> >> > >>> > > >> > up
> >> > >>> > > >> > > >> to
> >> > >>> > > >> > > >>>> one year since the last minor release (0.4.y,
> 1.5.y)
> >> in
> >> > >>> that
> >> > >>> > > >> line")
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> But additional support might be available by
> special
> >> > >>> request.
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined
> >> for a
> >> > >>> > future
> >> > >>> > > >> major
> >> > >>> > > >> > > >>>> release stored? Is it visible anywhere?
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> I suppose Jira tickets targeting the next major
> >> release
> >> > >>> > > >> > > >>> could/should/would
> >> > >>> > > >> > > >>>> (do?) push branches. That seems weak in the face
> of
> >> a
> >> > >>> > probable
> >> > >>> > > >> > > >> stampede
> >> > >>> > > >> > > >>>> towards the fire exit of a major release, but
> it's a
> >> > >>> start.
> >> > >>> > > I'm
> >> > >>> > > >> not
> >> > >>> > > >> > > >>> aware
> >> > >>> > > >> > > >>>> of any great solutions here, certainly not for an
> >> > >>> open-source
> >> > >>> > > >> > project.
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
> >> > >>> > joe.witt@gmail.com>
> >> > >>> > > >> > wrote:
> >> > >>> > > >> > > >>>>
> >> > >>> > > >> > > >>>>> James,
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> These are great questions to frame and test the
> >> model.
> >> > >>> So
> >> > >>> > > let's
> >> > >>> > > >> > > >>>>> attempt to address them agains the model.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> Here is the language for that model at this time:
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> - 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'
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> So with those above let's review 1 through 5 in
> >> turn.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> 1.) Commits merged to master today are destined
> for
> >> > the
> >> > >>> next
> >> > >>> > > >> minor
> >> > >>> > > >> > > >>>>> release, currently 0.6.0, by default?
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> Master is for whatever is the most leading edge
> >> > release
> >> > >>> line
> >> > >>> > > >> > working
> >> > >>> > > >> > > >>>>> toward the next release. At the time that a
> minor
> >> > >>> release
> >> > >>> > > occurs
> >> > >>> > > >> > > >>>>> against that release line then it branches off
> into
> >> a
> >> > >>> > > >> support/x.y.*
> >> > >>> > > >> > > >>>>> branch for any further efforts against it.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> 2.) Is master always open for merging new code,
> or
> >> are
> >> > >>> there
> >> > >>> > > >> > > >>> restrictions
> >> > >>> > > >> > > >>>>> before or after releases?
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> I believe master would be always open for new
> code.
> >> > >>> From
> >> > >>> > some
> >> > >>> > > >> > point
> >> > >>> > > >> > > >>>>> at which a release is considered feature complete
> >> then
> >> > >>> > further
> >> > >>> > > >> > > feature
> >> > >>> > > >> > > >>>>> enhancements need to go on master as part of the
> >> next
> >> > >>> > release
> >> > >>> > > >> > effort.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> The most recent minor release line of a major
> line
> >> > will
> >> > >>> be
> >> > >>> > > >> > supported
> >> > >>> > > >> > > >>>>> for up to one year from whenever it was released
> >> where
> >> > >>> > > support is
> >> > >>> > > >> > for
> >> > >>> > > >> > > >>>>> bug fixes for security or data loss related
> items.
> >> > >>> Releases
> >> > >>> > > for
> >> > >>> > > >> > > older
> >> > >>> > > >> > > >>>>> minor lines should be considered on a case by
> case
> >> > >>> basis and
> >> > >>> > > if
> >> > >>> > > >> > > >>>>> requested. Otherwise the basic premise is the
> train
> >> > is
> >> > >>> > moving
> >> > >>> > > >> > > >>>>> forward.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined
> >> for
> >> > a
> >> > >>> > future
> >> > >>> > > >> > major
> >> > >>> > > >> > > >>>>> release stored? Is it visible anywhere?
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> It must be visible. It should be placed into a
> >> branch
> >> > >>> until
> >> > >>> > > such
> >> > >>> > > >> > > >>>>> time that it is ready to become the new master.
> >> That
> >> > >>> time
> >> > >>> > > would
> >> > >>> > > >> be
> >> > >>> > > >> > > >>>>> when the next release will be for that line.
> When I
> >> > >>> think
> >> > >>> > > about
> >> > >>> > > >> > this
> >> > >>> > > >> > > >>>>> against the stated model we could probably tweak
> the
> >> > >>> wording
> >> > >>> > > to
> >> > >>> > > >> > > better
> >> > >>> > > >> > > >>>>> articulate that. I think it was what was meant
> with
> >> > >>> 'when
> >> > >>> > > master
> >> > >>> > > >> > has
> >> > >>> > > >> > > >>>>> no releases we will backport...' but that is
> >> unclear.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0
> >> would
> >> > >>> > > eligible
> >> > >>> > > >> to
> >> > >>> > > >> > be
> >> > >>> > > >> > > >>>>> backported only to the last minor release in the
> 0.x
> >> > >>> line,
> >> > >>> > or
> >> > >>> > > to
> >> > >>> > > >> > all
> >> > >>> > > >> > > >>> minor
> >> > >>> > > >> > > >>>>> releases in the 0.x line?
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> Only to the most recent minor release of any
> still
> >> > >>> supported
> >> > >>> > > >> major
> >> > >>> > > >> > > >>>>> line. However, the catch of 'case by case'
> >> > >>> determination
> >> > >>> > for
> >> > >>> > > >> older
> >> > >>> > > >> > > >>>>> minor lines is still in play. Basically if
> someone
> >> > >>> requests
> >> > >>> > > it
> >> > >>> > > >> and
> >> > >>> > > >> > > >>>>> can get enough momentum for it then it should be
> no
> >> > >>> problem
> >> > >>> > to
> >> > >>> > > >> > > produce
> >> > >>> > > >> > > >>>>> such a release.
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> Thanks
> >> > >>> > > >> > > >>>>> Joe
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
> >> > >>> > jvwing@gmail.com
> >> > >>> > > >
> >> > >>> > > >> > > wrote:
> >> > >>> > > >> > > >>>>>> I have some rhetorical questions for discussion
> of
> >> > the
> >> > >>> > > branching
> >> > >>> > > >> > > >> model:
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> 1.) Commits merged to master today are destined
> for
> >> > the
> >> > >>> > next
> >> > >>> > > >> minor
> >> > >>> > > >> > > >>>>> release,
> >> > >>> > > >> > > >>>>>> currently 0.6.0, by default?
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> 2.) Is master always open for merging new code,
> or
> >> > are
> >> > >>> > there
> >> > >>> > > >> > > >>> restrictions
> >> > >>> > > >> > > >>>>>> before or after releases?
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code
> destined
> >> > for a
> >> > >>> > > future
> >> > >>> > > >> > major
> >> > >>> > > >> > > >>>>>> release stored? Is it visible anywhere?
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0
> >> > would
> >> > >>> > > eligible
> >> > >>> > > >> to
> >> > >>> > > >> > > be
> >> > >>> > > >> > > >>>>>> backported only to the last minor release in the
> >> 0.x
> >> > >>> line,
> >> > >>> > > or to
> >> > >>> > > >> > all
> >> > >>> > > >> > > >>>>> minor
> >> > >>> > > >> > > >>>>>> releases in the 0.x line?
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> >> > >>> > > joe.witt@gmail.com>
> >> > >>> > > >> > > >> wrote:
> >> > >>> > > >> > > >>>>>>
> >> > >>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to
> turn
> >> it
> >> > >>> more
> >> > >>> > > >> toward
> >> > >>> > > >> > a
> >> > >>> > > >> > > >>>>>>> proposal as we're at a point now where we need
> to
> >> > >>> start
> >> > >>> > > >> executing
> >> > >>> > > >> > > >> some
> >> > >>> > > >> > > >>>>>>> of these approaches. We're actually already
> >> seeing
> >> > it
> >> > >>> > take
> >> > >>> > > >> form
> >> > >>> > > >> > in
> >> > >>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch
> >> > (which
> >> > >>> is
> >> > >>> > for
> >> > >>> > > >> > 0.6.0
> >> > >>> > > >> > > >> at
> >> > >>> > > >> > > >>>>>>> this point).
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>>> The proposal then for Git processes based on
> the
> >> > other
> >> > >>> > > thread
> >> > >>> > > >> [1]
> >> > >>> > > >> > > >>>>>>> where we outline a support model:
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>>> - 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
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>>> [1]
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > >
> >> > >>> > > >> >
> >> > >>> > > >>
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>>> Thanks
> >> > >>> > > >> > > >>>>>>> Joe
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> >> > >>> > > joe.witt@gmail.com>
> >> > >>> > > >> > > >> wrote:
> >> > >>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good
> to
> >> > >>> discuss
> >> > >>> > > >> > specific
> >> > >>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
> >> > >>> consensus
> >> > >>> > > >> > > discussion
> >> > >>> > > >> > > >>>>>>>> around Tony's original intent (as I read
> it). So
> >> > >>> kicked
> >> > >>> > > off a
> >> > >>> > > >> > > >>>>>>>> discussion back at that level.
> >> > >>> > > >> > > >>>>>>>>
> >> > >>> > > >> > > >>>>>>>>
> >> > >>> > > >> > > >>>>>>>>
> >> > >>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> >> > >>> > > trkurc@gmail.com>
> >> > >>> > > >> > > >> wrote:
> >> > >>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any
> of
> >> > the
> >> > >>> > > plugins
> >> > >>> > > >> > that
> >> > >>> > > >> > > >> are
> >> > >>> > > >> > > >>>>>>> used.
> >> > >>> > > >> > > >>>>>>>>> I have worked on some other projects
> >> > (unfortunately
> >> > >>> not
> >> > >>> > > open
> >> > >>> > > >> > > >> source)
> >> > >>> > > >> > > >>>>>>> that
> >> > >>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever
> >> > using
> >> > >>> a
> >> > >>> > > plugin.
> >> > >>> > > >> > > Nice
> >> > >>> > > >> > > >>>>> side
> >> > >>> > > >> > > >>>>>>>>> effect is that I believe this got me better
> at
> >> > using
> >> > >>> > git,
> >> > >>> > > and
> >> > >>> > > >> > > >>>>> generally
> >> > >>> > > >> > > >>>>>>> we
> >> > >>> > > >> > > >>>>>>>>> all got better at managing merge pain.
> >> > >>> > > >> > > >>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're
> >> > >>> operating
> >> > >>> > the
> >> > >>> > > way
> >> > >>> > > >> > we
> >> > >>> > > >> > > >> are
> >> > >>> > > >> > > >>>>>>> now is
> >> > >>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial
> bar
> >> > for a
> >> > >>> > > patch is
> >> > >>> > > >> > > "can
> >> > >>> > > >> > > >>> be
> >> > >>> > > >> > > >>>>>>>>> merged into master", and we have our friend
> >> Travis
> >> > >>> to
> >> > >>> > make
> >> > >>> > > >> this
> >> > >>> > > >> > > >> even
> >> > >>> > > >> > > >>>>>>> easier
> >> > >>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies
> things.
> >> > If
> >> > >>> a
> >> > >>> > > bugfix
> >> > >>> > > >> is
> >> > >>> > > >> > > >>>>> "patch
> >> > >>> > > >> > > >>>>>>>>> needs to be able to apply onto the current
> >> release
> >> > >>> in
> >> > >>> > > >> progress,
> >> > >>> > > >> > > >>>>> master,
> >> > >>> > > >> > > >>>>>>> and
> >> > >>> > > >> > > >>>>>>>>> several other versions we're supporting, with
> >> > >>> possibly
> >> > >>> > > >> > > drastically
> >> > >>> > > >> > > >>>>>>>>> different code", well then things get
> >> interesting.
> >> > >>> > > >> > > >>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson
> >> > Margulies <
> >> > >>> > > >> > > >>>>>>> bimargulies@gmail.com>
> >> > >>> > > >> > > >>>>>>>>> wrote:
> >> > >>> > > >> > > >>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>> The issue tracker
> >> > >>> > > >> > > >>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > >
> >> > >>> > > >> >
> >> > >>> > > >>
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> >
> >>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >> > >>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
> >> > >>> > > >> > > >>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson
> >> > Margulies
> >> > >>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> >> > >>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow
> plugin.
> >> It
> >> > >>> worked
> >> > >>> > > >> great,
> >> > >>> > > >> > > >>>>> until
> >> > >>> > > >> > > >>>>>>> it
> >> > >>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible,
> >> > inexplicable,
> >> > >>> > merge
> >> > >>> > > >> > > >> problems.
> >> > >>> > > >> > > >>>>> No
> >> > >>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
> >> > >>> > > >> > > >>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
> >> > >>> > > >> > > >>>>>>>>>>>
> >> > >>> > > >> >
> >> https://github.com/egineering-llc/gitflow-helper-maven-plugin
> >> > .
> >> > >>> > > >> > > >>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam
> Taft <
> >> > >>> > > >> > adam@adamtaft.com
> >> > >>> > > >> > > >
> >> > >>> > > >> > > >>>>>>> wrote:
> >> > >>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is
> >> using
> >> > >>> it in
> >> > >>> > > >> > > >> combination
> >> > >>> > > >> > > >>>>>>> with
> >> > >>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and
> releases
> >> > are
> >> > >>> > > tracking
> >> > >>> > > >> > > >>>>> closely
> >> > >>> > > >> > > >>>>>>> with
> >> > >>> > > >> > > >>>>>>>>>> the
> >> > >>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its
> own,
> >> > >>> doesn't
> >> > >>> > > keep
> >> > >>> > > >> > the
> >> > >>> > > >> > > >> pom
> >> > >>> > > >> > > >>>>>>>>>> version
> >> > >>> > > >> > > >>>>>>>>>>>> updated with the git release names.
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>> Because of the general importance of
> keeping
> >> > >>> releases
> >> > >>> > > and
> >> > >>> > > >> > tags
> >> > >>> > > >> > > >>>>>>>>>> synchronized
> >> > >>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we
> do,
> >> > it
> >> > >>> > needs
> >> > >>> > > to
> >> > >>> > > >> be
> >> > >>> > > >> > > >>>>>>> approached
> >> > >>> > > >> > > >>>>>>>>>>>> with tools that are available through
> maven
> >> > >>> rather
> >> > >>> > than
> >> > >>> > > >> from
> >> > >>> > > >> > > >> git.
> >> > >>> > > >> > > >>>>>>> The
> >> > >>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad)
> doesn't
> >> > >>> directly
> >> > >>> > > help
> >> > >>> > > >> > > deal
> >> > >>> > > >> > > >>>>> with
> >> > >>> > > >> > > >>>>>>>>>> this
> >> > >>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool,
> not a
> >> > >>> maven
> >> > >>> > > tool.
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success,
> the
> >> > >>> > jgitflow
> >> > >>> > > [1]
> >> > >>> > > >> > > >>>>> plugin,
> >> > >>> > > >> > > >>>>>>> which
> >> > >>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the
> >> gitflow
> >> > >>> model
> >> > >>> > > for a
> >> > >>> > > >> > > >> maven
> >> > >>> > > >> > > >>>>>>>>>> project.
> >> > >>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI,
> >> because
> >> > >>> it
> >> > >>> > > insists
> >> > >>> > > >> > > that
> >> > >>> > > >> > > >>>>> the
> >> > >>> > > >> > > >>>>>>>>>> master
> >> > >>> > > >> > > >>>>>>>>>>>> branch is strictly used for published
> release
> >> > >>> tags
> >> > >>> > (as
> >> > >>> > > per
> >> > >>> > > >> > the
> >> > >>> > > >> > > >>>>>>> strict
> >> > >>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this,
> in
> >> > >>> reference
> >> > >>> > > to
> >> > >>> > > >> how
> >> > >>> > > >> > > >> some
> >> > >>> > > >> > > >>>>>>>>>> plugins
> >> > >>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven
> >> > >>> synchronization
> >> > >>> > > issue.
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad
> >> Guidry <
> >> > >>> > > >> > > >>>>> thadguidry@gmail.com
> >> > >>> > > >> > > >>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>> wrote:
> >> > >>> > > >> > > >>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with
> >> Git-flow.
> >> > >>> Your
> >> > >>> > > >> Master
> >> > >>> > > >> > > >>>>> become
> >> > >>> > > >> > > >>>>>>>>>> primary
> >> > >>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
> >> > >>> branches
> >> > >>> > > off of
> >> > >>> > > >> > > >> it)..
> >> > >>> > > >> > > >>>>>>> while
> >> > >>> > > >> > > >>>>>>>>>> you
> >> > >>> > > >> > > >>>>>>>>>>>>> continue to have release branches that
> can
> >> > have
> >> > >>> hot
> >> > >>> > > fix
> >> > >>> > > >> > > >> branches
> >> > >>> > > >> > > >>>>>>> off of
> >> > >>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release
> >> > branch
> >> > >>> ! -
> >> > >>> > > bad
> >> > >>> > > >> > > >>>>> practice !
> >> > >>> > > >> > > >>>>>>> )
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make
> it
> >> > >>> easy for
> >> > >>> > > >> > everyone
> >> > >>> > > >> > > >> to
> >> > >>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain
> >> the
> >> > >>> > > >> > understanding.
> >> > >>> > > >> > > >> Its
> >> > >>> > > >> > > >>>>>>> really
> >> > >>> > > >> > > >>>>>>>>>>>>> that easy.
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
> >> > >>> git-flow
> >> > >>> > ...
> >> > >>> > > >> and
> >> > >>> > > >> > > >> tools
> >> > >>> > > >> > > >>>>>>> like
> >> > >>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree,
> >> etc...have
> >> > >>> > > Git-flow
> >> > >>> > > >> > > either
> >> > >>> > > >> > > >>>>>>> built
> >> > >>> > > >> > > >>>>>>>>>> in or
> >> > >>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to
> live
> >> on
> >> > >>> the
> >> > >>> > > command
> >> > >>> > > >> > > >> line,
> >> > >>> > > >> > > >>>>>>> then
> >> > >>> > > >> > > >>>>>>>>>> that
> >> > >>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in
> the
> >> > >>> above
> >> > >>> > > link.
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>>>> Thad
> >> > >>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <
> >> > https://www.google.com/+ThadGuidry
> >> > >>> >
> >> > >>> > > >> > > >>>>>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>>>>
> >> > >>> > > >> > > >>>>>>>
> >> > >>> > > >> > > >>>>>
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>>
> >> > >>> > > >> > > >>
> >> > >>> > > >> > >
> >> > >>> > > >> > >
> >> > >>> > > >> >
> >> > >>> > > >>
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
>
Re: [DISCUSS] git branching model
Posted by Andy LoPresto <al...@apache.org>.
I wrote up a quick guide for reviewers to apply the patches to multiple support branches on the wiki [1].
[1] https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-Stepstomerge/closepullrequestswithtwomainbranches <https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-Stepstomerge/closepullrequestswithtwomainbranches>
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Apr 4, 2016, at 4:01 PM, Sean Busbey <bu...@apache.org> wrote:
>
> On Mon, Apr 4, 2016 at 4:40 PM, Adam Lamar <ad...@gmail.com> wrote:
>> On Mon, Apr 4, 2016 at 11:14 AM, Sean Busbey <bu...@apache.org> wrote:
>>> You're correct, a github PR only targets a single branch and Travis-CI
>>> only checks how the PR does at its own commit hash (that is, it
>>> doesn't even check what the target branch would look like post-merge).
>>>
>>
>> Hey Sean, it looks like Travis-CI does merge into the specified merge
>> branch before running. For example, my ListS3 PR [1] has commit
>> 2f7e89e, but the Travis-CI status page [1] shows commit e0868c2. If
>> you find that in github [2] you'll see it is the merge of 2f7e89e and
>> 6f5fb59, where 6f5fb59 is the location of master when I submitted the
>> PR.
>>
>
> Excellent. I am very happy to find that I'm incorrect. I must just be
> used to using Travis-CI with very old PRs. :)
Re: [DISCUSS] git branching model
Posted by Sean Busbey <bu...@apache.org>.
On Mon, Apr 4, 2016 at 4:40 PM, Adam Lamar <ad...@gmail.com> wrote:
> On Mon, Apr 4, 2016 at 11:14 AM, Sean Busbey <bu...@apache.org> wrote:
>> You're correct, a github PR only targets a single branch and Travis-CI
>> only checks how the PR does at its own commit hash (that is, it
>> doesn't even check what the target branch would look like post-merge).
>>
>
> Hey Sean, it looks like Travis-CI does merge into the specified merge
> branch before running. For example, my ListS3 PR [1] has commit
> 2f7e89e, but the Travis-CI status page [1] shows commit e0868c2. If
> you find that in github [2] you'll see it is the merge of 2f7e89e and
> 6f5fb59, where 6f5fb59 is the location of master when I submitted the
> PR.
>
Excellent. I am very happy to find that I'm incorrect. I must just be
used to using Travis-CI with very old PRs. :)
Re: [DISCUSS] git branching model
Posted by Adam Lamar <ad...@gmail.com>.
On Mon, Apr 4, 2016 at 11:14 AM, Sean Busbey <bu...@apache.org> wrote:
> You're correct, a github PR only targets a single branch and Travis-CI
> only checks how the PR does at its own commit hash (that is, it
> doesn't even check what the target branch would look like post-merge).
>
Hey Sean, it looks like Travis-CI does merge into the specified merge
branch before running. For example, my ListS3 PR [1] has commit
2f7e89e, but the Travis-CI status page [1] shows commit e0868c2. If
you find that in github [2] you'll see it is the merge of 2f7e89e and
6f5fb59, where 6f5fb59 is the location of master when I submitted the
PR.
If the branch is squashed prior to the final merge, then Travis-CI
will be run a second time against the latest master or pretty close to
it, depending on how quickly a committer comes along :)
Adam
[1] https://github.com/apache/nifi/pull/238
[2] https://travis-ci.org/apache/nifi/builds/114423137
[3] https://github.com/apache/nifi/commit/e0868c242503cda3c4ca14140164e0e7f3f7a8fe
Re: [DISCUSS] git branching model
Posted by Sean Busbey <bu...@apache.org>.
You're correct, a github PR only targets a single branch and Travis-CI
only checks how the PR does at its own commit hash (that is, it
doesn't even check what the target branch would look like post-merge).
On Mon, Apr 4, 2016 at 12:05 PM, Matt Gilman <ma...@gmail.com> wrote:
> To my knowledge, when you open a PR in GitHub it only allows the
> contributor to select a single branch. The reviewer would need to check the
> compatibility if that contribution needs to be applied to both. Depending
> on the contribution, a separate PR may be required as the codebases
> diverge. In practice though, most of the work on master (1.x) will focus on
> the framework which is where diverging is most likely to occur.
> Consequently, framework bug fixes are the most likely place where we may
> need separate PRs.
>
> On Mon, Apr 4, 2016 at 12:46 PM, Tony Kurc <tr...@gmail.com> wrote:
>
>> Is travis ci / githib able to give immediate feedback if a PR doesn't merge
>> into both?
>>
>> On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman <ma...@gmail.com>
>> wrote:
>>
>> > All,
>> >
>> > I have completed the branching discussed last week.
>> >
>> > - master contains the current 1.x baseline - Future 1.x releases will
>> start
>> > from here
>> > - 0.x contains the 0.x baseline - Future 0.x releases will start from
>> here
>> >
>> > Going forward all PRs will need to be merged the either or both branches
>> as
>> > appropriate to ensure it's included in subsequent releases. I will be
>> > updating the quick start and contributor guide to describe the
>> distinction
>> > between the two branches.
>> >
>> > Thanks!
>> >
>> > Matt
>> >
>> > On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <ma...@gmail.com>
>> > wrote:
>> >
>> > > The majority consensus is to have master point to our 1.x baseline
>> going
>> > > forward. Unless there are any strong objections I will set everything
>> up
>> > on
>> > > Monday (4/4) morning.
>> > >
>> > > - Create a 0.x branch for all future 0.x releases based on the current
>> > > state of master.
>> > > - Apply all 1.x commits from the temporary 1.x branch to master.
>> > > - Delete the temporary 1.x branch.
>> > > - Update the quickstart page and contribution guide to detail the
>> > > distinction between the 0.x and master branches.
>> > > - Send another email to @dev once this has been completed.
>> > >
>> > > Reminder: Going forward once this has been completed all commits will
>> > need
>> > > to be made to both branches as appropriate.
>> > >
>> > > Thanks!
>> > >
>> > > Matt
>> > >
>> > > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <ma...@gmail.com>
>> > > wrote:
>> > >
>> > >> Matt,
>> > >>
>> > >> I agree that the PRs would need to be merged to both baselines at
>> > >> contribution time. If the contribution applies cleanly the reviewer
>> > could
>> > >> certainly handle the commit themselves. However, if additional code
>> > changes
>> > >> are required because the baselines have diverged, the contributor
>> would
>> > >> probably need to submit another PR. This additional effort should only
>> > be
>> > >> necessary until we're able to perform the first 1.x release.
>> > >>
>> > >> Aldrin,
>> > >>
>> > >> I definitely understand your thoughts regarding (1) and (2). This is
>> why
>> > >> I wanted to pose the options before just jumping into one approach vs
>> > the
>> > >> other. I personally prefer the GitHub style PR process. I realize this
>> > is
>> > >> more cumbersome but hopefully the number of conflicts should be small
>> as
>> > >> folks are already starting to focus their efforts on the framework for
>> > 1.x.
>> > >>
>> > >> Matt
>> > >>
>> > >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> I think I prefer option 2 considering, what may be the incorrect
>> > >>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be
>> > easier.
>> > >>> Based on outstanding PRs/Patches in conjunction with release cadence
>> > >>> there
>> > >>> will be more 0.x releases planned. Until we reached the point where
>> the
>> > >>> first 1.x release is in sight, I think (2) makes sense just from
>> > >>> minimizing
>> > >>> impedance where the majority of effort will occur (new/updated
>> > >>> extensions)
>> > >>> and then switching to (1) when we are scheduling 1.x as next
>> (exclusive
>> > >>> of
>> > >>> any patch builds). This seems to work out when I try to reason about
>> > it,
>> > >>> but admittedly, am coming at this heavily from my own anecdotal
>> > >>> perspective
>> > >>> given my flow of reviewing.
>> > >>>
>> > >>> Matt, excellent points to consider.
>> > >>>
>> > >>> Do not want to go too much on a tangent from the current
>> conversation,
>> > >>> but
>> > >>> I think we need to harness automation as much as possible. Not sure
>> > >>> Travis
>> > >>> can do this or do so easily (short of two PRs) and this may arguably
>> > >>> shift
>> > >>> things in favor of patches and the model that the other ASF projects
>> > >>> utilize with buildbot. Getting as much done asynchronously for us is
>> > >>> obviously important but we also have to strive to avoid a contrib
>> > process
>> > >>> that is too cumbersome as well.
>> > >>>
>> > >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>> > I like option 1 as well.
>> > >>> >
>> > >>> > In the case where a fix is to be put into both branches, will the
>> > >>> developer
>> > >>> > be responsible for issuing 2 PRs / patches, one against each
>> branch?
>> > >>> This
>> > >>> > would help in the case that the PR/patch against 0.x won't merge
>> > >>> cleanly
>> > >>> > into master; however the reviewer(s) would need to make sure there
>> > >>> were no
>> > >>> > breaking changes as a result of the manual merge to master. An
>> > >>> alternative
>> > >>> > is that the reviewer(s) do the forward-port, which I don't think
>> is a
>> > >>> good
>> > >>> > idea. However the reviewer would need to make sure the PR(s) are
>> > >>> against
>> > >>> > the correct branch. For example, all current PRs would need to be
>> > >>> > "backported" to the new 0.x branch.
>> > >>> >
>> > >>> > Also, I would think the PRs/patches need to be merged at the same
>> > time
>> > >>> (or
>> > >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but
>> > getting
>> > >>> > forgotten/missed for 1.x).
>> > >>> >
>> > >>> > Thoughts? Thanks,
>> > >>> > Matt
>> > >>> >
>> > >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com>
>> > wrote:
>> > >>> >
>> > >>> > > I too prefer option 1
>> > >>> > >
>> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu>
>> > >>> wrote:
>> > >>> > > > I agree with Tony on option 1. I think it makes sense for
>> > master
>> > >>> to
>> > >>> > be
>> > >>> > > > the most "advanced" branch. New features will then always be
>> > >>> applied
>> > >>> > to
>> > >>> > > > master, and optionally to other branches for older version
>> > support
>> > >>> as
>> > >>> > > > applicable / desired.
>> > >>> > > >
>> > >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com>
>> > >>> wrote:
>> > >>> > > >
>> > >>> > > >> I like option 1
>> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <
>> > matt.c.gilman@gmail.com>
>> > >>> > > wrote:
>> > >>> > > >>
>> > >>> > > >> > Hello,
>> > >>> > > >> >
>> > >>> > > >> > With NiFi 0.6.0 officially released and our support strategy
>> > >>> defined
>> > >>> > > [1],
>> > >>> > > >> > I'd like to revisit and propose some options for supporting
>> > >>> both a
>> > >>> > 1.x
>> > >>> > > >> > branch and 0.x branch concurrently. We need an official
>> place
>> > >>> where
>> > >>> > > these
>> > >>> > > >> > efforts can be worked, contributed to, and collaborated with
>> > the
>> > >>> > > >> community.
>> > >>> > > >> > I've already created a 1.x branch as a temporary place for
>> > this
>> > >>> > > codebase
>> > >>> > > >> to
>> > >>> > > >> > live until we agree to an approach.
>> > >>> > > >> >
>> > >>> > > >> > Either option I'm proposing will require
>> > >>> PRs/contributions/patches
>> > >>> > to
>> > >>> > > be
>> > >>> > > >> > applied to both branches as applicable. This means that the
>> > >>> > > contributor
>> > >>> > > >> or
>> > >>> > > >> > the reviewer will need to be able to apply the commits in
>> both
>> > >>> > places
>> > >>> > > if
>> > >>> > > >> > it's necessary. For instance, framework code has already
>> > started
>> > >>> > > >> diverging
>> > >>> > > >> > from the current master so any framework change may not need
>> > to
>> > >>> be
>> > >>> > > >> applied
>> > >>> > > >> > to both if the changeset is not applicable to the 1.x
>> > baseline.
>> > >>> > > >> >
>> > >>> > > >> > The only question at the moment is what master will refer
>> to.
>> > >>> > > >> >
>> > >>> > > >> > 1) Create a branch for 0.x and allow master to become the
>> 1.x
>> > >>> > baseline
>> > >>> > > >> > going forward. Future 0.x releases will be performed from
>> the
>> > >>> 0.x
>> > >>> > > branch.
>> > >>> > > >> > 2) Continuing working on the 1.x branch as is. Allow master
>> to
>> > >>> > > continue
>> > >>> > > >> to
>> > >>> > > >> > servicing 0.x releases. Once a 1.x release is made, create
>> the
>> > >>> 0.x
>> > >>> > > branch
>> > >>> > > >> > and then allow master to service 1.x releases.
>> > >>> > > >> >
>> > >>> > > >> > In short, when do we want master to point to the 1.x
>> baseline?
>> > >>> When
>> > >>> > > >> should
>> > >>> > > >> > we create a branch where 0.x releases will be made from.
>> > >>> Regardless,
>> > >>> > > >> > contributions will need to be performed to both places as
>> > >>> > applicable.
>> > >>> > > >> >
>> > >>> > > >> > Thanks.
>> > >>> > > >> >
>> > >>> > > >> > Matt
>> > >>> > > >> >
>> > >>> > > >> > [1]
>> > >>> > > >> >
>> > >>> > > >> >
>> > >>> > > >>
>> > >>> > >
>> > >>> >
>> > >>>
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> > >>> > > >> >
>> > >>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
>> > >>> > > r.p.miskin@gmail.com>
>> > >>> > > >> > wrote:
>> > >>> > > >> >
>> > >>> > > >> > > I guess it will depend how much change is expected on the
>> > >>> > > maintenance
>> > >>> > > >> > > branches,
>> > >>> > > >> > > but if you want every change in the maintenance branch to
>> go
>> > >>> into
>> > >>> > > the
>> > >>> > > >> > > main-line branch then there is little difference from a
>> > >>> conflict
>> > >>> > > point
>> > >>> > > >> of
>> > >>> > > >> > > view
>> > >>> > > >> > > between a series of cherry-picks and a merge.
>> > >>> > > >> > >
>> > >>> > > >> > > Either way, it is just another approach to consider.
>> There’s
>> > >>> more
>> > >>> > > than
>> > >>> > > >> > one
>> > >>> > > >> > > way to do it, and I suspect there isn’t any solution that
>> > >>> makes it
>> > >>> > > >> > trivial.
>> > >>> > > >> > >
>> > >>> > > >> > > Cheers,
>> > >>> > > >> > > Richard
>> > >>> > > >> > >
>> > >>> > > >> > >
>> > >>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <
>> > aldrinpiri@gmail.com
>> > >>> >
>> > >>> > > wrote:
>> > >>> > > >> > > >
>> > >>> > > >> > > > On board with Tony's points. I think the realities of
>> > >>> merging
>> > >>> > in
>> > >>> > > >> > > practice
>> > >>> > > >> > > > when that "breaking point" of sorts occurs will make the
>> > >>> > > complexity
>> > >>> > > >> and
>> > >>> > > >> > > > overhead quite difficult and maybe even more error prone
>> > >>> than
>> > >>> > the
>> > >>> > > >> > cherry
>> > >>> > > >> > > > picking approach with some additional guidelines. When
>> > the
>> > >>> > > codebase
>> > >>> > > >> > > > drastically changes, the merge conflicts could be quite
>> > >>> severe
>> > >>> > and
>> > >>> > > >> > > without
>> > >>> > > >> > > > a good knowledge of each part of the codebase involved
>> > >>> during
>> > >>> > that
>> > >>> > > >> > > process,
>> > >>> > > >> > > > a committer may introduce regressions.
>> > >>> > > >> > > >
>> > >>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <
>> > >>> trkurc@gmail.com>
>> > >>> > > wrote:
>> > >>> > > >> > > >
>> > >>> > > >> > > >> the reason I like applying patches to both lines is
>> that
>> > >>> once
>> > >>> > > code
>> > >>> > > >> > > begins
>> > >>> > > >> > > >> to diverge, cleanly merging into one codebase can be
>> > >>> > impossible.
>> > >>> > > >> > having
>> > >>> > > >> > > >> good practices for managing patches and where they
>> apply
>> > is
>> > >>> > > >> paramount
>> > >>> > > >> > > for
>> > >>> > > >> > > >> success.
>> > >>> > > >> > > >>
>> > >>> > > >> > > >> I expect that divergence to happen with 1.x. I wanted
>> to
>> > >>> get
>> > >>> > in a
>> > >>> > > >> > battle
>> > >>> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
>> > >>> patches
>> > >>> > > >> COULD
>> > >>> > > >> > be
>> > >>> > > >> > > >> applied to both in the manner you described.
>> > >>> > > >> > > >>
>> > >>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
>> > >>> tickets
>> > >>> > > >> marked
>> > >>> > > >> > > for
>> > >>> > > >> > > >> 0.5.1 had the right patches in the support branch, and
>> > some
>> > >>> > > didn't,
>> > >>> > > >> > so I
>> > >>> > > >> > > >> think "lesson learned". I do like in the apache
>> > >>> infrastructure
>> > >>> > > that
>> > >>> > > >> if
>> > >>> > > >> > > >> commits have the appropriate ticket in their commit
>> > >>> message,
>> > >>> > the
>> > >>> > > >> jira
>> > >>> > > >> > > will
>> > >>> > > >> > > >> have the list of commits and branches those commits
>> were
>> > >>> > applies
>> > >>> > > to.
>> > >>> > > >> > > >> However, I think we may need to revisit commit message
>> > >>> > > "hygiene" if
>> > >>> > > >> > we
>> > >>> > > >> > > >> relied on this instead of more manual review.
>> > >>> > > >> > > >>
>> > >>> > > >> > > >>
>> > >>> > > >> > > >>
>> > >>> > > >> > > >>
>> > >>> > > >> > > >>
>> > >>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
>> > >>> > > >> r.p.miskin@gmail.com
>> > >>> > > >> > >
>> > >>> > > >> > > >> wrote:
>> > >>> > > >> > > >>
>> > >>> > > >> > > >>> Hi,
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>> On a couple of work projects we found that the
>> approach
>> > of
>> > >>> > > >> > > cherry-picking
>> > >>> > > >> > > >>> commits can lead to an unnecessarily complicated
>> history
>> > >>> where
>> > >>> > > the
>> > >>> > > >> > same
>> > >>> > > >> > > >>> piece of work appears as multiple separate commits on
>> > >>> > different
>> > >>> > > >> > > branches.
>> > >>> > > >> > > >>> This can then make it hard to be confident that a bug
>> > fix
>> > >>> has
>> > >>> > > been
>> > >>> > > >> > > >> applied
>> > >>> > > >> > > >>> to all relevant branches. We found that it works
>> better
>> > >>> to aim
>> > >>> > > to
>> > >>> > > >> > > commit
>> > >>> > > >> > > >>> changes to the lowest applicable branch, and then
>> > >>> regularly
>> > >>> > > merge
>> > >>> > > >> > those
>> > >>> > > >> > > >>> branches to master. This approach is based on the
>> > git-flow
>> > >>> > > model (
>> > >>> > > >> > > >>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>> > <
>> > >>> > > >> > > >>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>> > >>> >).
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>> Looking at the repo there are already a few commits
>> that
>> > >>> are
>> > >>> > > >> > duplicated
>> > >>> > > >> > > >> on
>> > >>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d
>> only
>> > >>> occur
>> > >>> > on
>> > >>> > > >> > 0.5.1,
>> > >>> > > >> > > >> and
>> > >>> > > >> > > >>> then that branch would get merged to master.
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>> Having the merge commits from the support branch to
>> > master
>> > >>> > > makes it
>> > >>> > > >> > > >>> explicit in the git history that all bug fixes (and
>> > >>> associated
>> > >>> > > >> tests)
>> > >>> > > >> > > >> have
>> > >>> > > >> > > >>> been pulled through to master.
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>> Cheers,
>> > >>> > > >> > > >>> Richard
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <
>> jvwing@gmail.com
>> > >
>> > >>> > wrote:
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and
>> > >>> see if
>> > >>> > > you
>> > >>> > > >> > > agree:
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> 1.) Commits merged to master today are destined for
>> the
>> > >>> next
>> > >>> > > minor
>> > >>> > > >> > > >>> release,
>> > >>> > > >> > > >>>> currently 0.6.0, by default?
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> By default, commits to master will be released in the
>> > >>> next
>> > >>> > > major
>> > >>> > > >> or
>> > >>> > > >> > > >> minor
>> > >>> > > >> > > >>>> release. No commits are included in
>> incremental/patch
>> > >>> > > releases by
>> > >>> > > >> > > >>> default.
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> support/0.5.x will be maintained until the first of
>> the
>> > >>> > > following
>> > >>> > > >> > > >> events:
>> > >>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major
>> > >>> release
>> > >>> > > line)
>> > >>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
>> > >>> release
>> > >>> > > >> lines
>> > >>> > > >> > up
>> > >>> > > >> > > >> to
>> > >>> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y)
>> in
>> > >>> that
>> > >>> > > >> line")
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> But additional support might be available by special
>> > >>> request.
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined
>> for a
>> > >>> > future
>> > >>> > > >> major
>> > >>> > > >> > > >>>> release stored? Is it visible anywhere?
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> I suppose Jira tickets targeting the next major
>> release
>> > >>> > > >> > > >>> could/should/would
>> > >>> > > >> > > >>>> (do?) push branches. That seems weak in the face of
>> a
>> > >>> > probable
>> > >>> > > >> > > >> stampede
>> > >>> > > >> > > >>>> towards the fire exit of a major release, but it's a
>> > >>> start.
>> > >>> > > I'm
>> > >>> > > >> not
>> > >>> > > >> > > >>> aware
>> > >>> > > >> > > >>>> of any great solutions here, certainly not for an
>> > >>> open-source
>> > >>> > > >> > project.
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
>> > >>> > joe.witt@gmail.com>
>> > >>> > > >> > wrote:
>> > >>> > > >> > > >>>>
>> > >>> > > >> > > >>>>> James,
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> These are great questions to frame and test the
>> model.
>> > >>> So
>> > >>> > > let's
>> > >>> > > >> > > >>>>> attempt to address them agains the model.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> Here is the language for that model at this time:
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> - 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'
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> So with those above let's review 1 through 5 in
>> turn.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> 1.) Commits merged to master today are destined for
>> > the
>> > >>> next
>> > >>> > > >> minor
>> > >>> > > >> > > >>>>> release, currently 0.6.0, by default?
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> Master is for whatever is the most leading edge
>> > release
>> > >>> line
>> > >>> > > >> > working
>> > >>> > > >> > > >>>>> toward the next release. At the time that a minor
>> > >>> release
>> > >>> > > occurs
>> > >>> > > >> > > >>>>> against that release line then it branches off into
>> a
>> > >>> > > >> support/x.y.*
>> > >>> > > >> > > >>>>> branch for any further efforts against it.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> 2.) Is master always open for merging new code, or
>> are
>> > >>> there
>> > >>> > > >> > > >>> restrictions
>> > >>> > > >> > > >>>>> before or after releases?
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> I believe master would be always open for new code.
>> > >>> From
>> > >>> > some
>> > >>> > > >> > point
>> > >>> > > >> > > >>>>> at which a release is considered feature complete
>> then
>> > >>> > further
>> > >>> > > >> > > feature
>> > >>> > > >> > > >>>>> enhancements need to go on master as part of the
>> next
>> > >>> > release
>> > >>> > > >> > effort.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> The most recent minor release line of a major line
>> > will
>> > >>> be
>> > >>> > > >> > supported
>> > >>> > > >> > > >>>>> for up to one year from whenever it was released
>> where
>> > >>> > > support is
>> > >>> > > >> > for
>> > >>> > > >> > > >>>>> bug fixes for security or data loss related items.
>> > >>> Releases
>> > >>> > > for
>> > >>> > > >> > > older
>> > >>> > > >> > > >>>>> minor lines should be considered on a case by case
>> > >>> basis and
>> > >>> > > if
>> > >>> > > >> > > >>>>> requested. Otherwise the basic premise is the train
>> > is
>> > >>> > moving
>> > >>> > > >> > > >>>>> forward.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined
>> for
>> > a
>> > >>> > future
>> > >>> > > >> > major
>> > >>> > > >> > > >>>>> release stored? Is it visible anywhere?
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> It must be visible. It should be placed into a
>> branch
>> > >>> until
>> > >>> > > such
>> > >>> > > >> > > >>>>> time that it is ready to become the new master.
>> That
>> > >>> time
>> > >>> > > would
>> > >>> > > >> be
>> > >>> > > >> > > >>>>> when the next release will be for that line. When I
>> > >>> think
>> > >>> > > about
>> > >>> > > >> > this
>> > >>> > > >> > > >>>>> against the stated model we could probably tweak the
>> > >>> wording
>> > >>> > > to
>> > >>> > > >> > > better
>> > >>> > > >> > > >>>>> articulate that. I think it was what was meant with
>> > >>> 'when
>> > >>> > > master
>> > >>> > > >> > has
>> > >>> > > >> > > >>>>> no releases we will backport...' but that is
>> unclear.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0
>> would
>> > >>> > > eligible
>> > >>> > > >> to
>> > >>> > > >> > be
>> > >>> > > >> > > >>>>> backported only to the last minor release in the 0.x
>> > >>> line,
>> > >>> > or
>> > >>> > > to
>> > >>> > > >> > all
>> > >>> > > >> > > >>> minor
>> > >>> > > >> > > >>>>> releases in the 0.x line?
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> Only to the most recent minor release of any still
>> > >>> supported
>> > >>> > > >> major
>> > >>> > > >> > > >>>>> line. However, the catch of 'case by case'
>> > >>> determination
>> > >>> > for
>> > >>> > > >> older
>> > >>> > > >> > > >>>>> minor lines is still in play. Basically if someone
>> > >>> requests
>> > >>> > > it
>> > >>> > > >> and
>> > >>> > > >> > > >>>>> can get enough momentum for it then it should be no
>> > >>> problem
>> > >>> > to
>> > >>> > > >> > > produce
>> > >>> > > >> > > >>>>> such a release.
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> Thanks
>> > >>> > > >> > > >>>>> Joe
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
>> > >>> > jvwing@gmail.com
>> > >>> > > >
>> > >>> > > >> > > wrote:
>> > >>> > > >> > > >>>>>> I have some rhetorical questions for discussion of
>> > the
>> > >>> > > branching
>> > >>> > > >> > > >> model:
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> 1.) Commits merged to master today are destined for
>> > the
>> > >>> > next
>> > >>> > > >> minor
>> > >>> > > >> > > >>>>> release,
>> > >>> > > >> > > >>>>>> currently 0.6.0, by default?
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> 2.) Is master always open for merging new code, or
>> > are
>> > >>> > there
>> > >>> > > >> > > >>> restrictions
>> > >>> > > >> > > >>>>>> before or after releases?
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined
>> > for a
>> > >>> > > future
>> > >>> > > >> > major
>> > >>> > > >> > > >>>>>> release stored? Is it visible anywhere?
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0
>> > would
>> > >>> > > eligible
>> > >>> > > >> to
>> > >>> > > >> > > be
>> > >>> > > >> > > >>>>>> backported only to the last minor release in the
>> 0.x
>> > >>> line,
>> > >>> > > or to
>> > >>> > > >> > all
>> > >>> > > >> > > >>>>> minor
>> > >>> > > >> > > >>>>>> releases in the 0.x line?
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
>> > >>> > > joe.witt@gmail.com>
>> > >>> > > >> > > >> wrote:
>> > >>> > > >> > > >>>>>>
>> > >>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn
>> it
>> > >>> more
>> > >>> > > >> toward
>> > >>> > > >> > a
>> > >>> > > >> > > >>>>>>> proposal as we're at a point now where we need to
>> > >>> start
>> > >>> > > >> executing
>> > >>> > > >> > > >> some
>> > >>> > > >> > > >>>>>>> of these approaches. We're actually already
>> seeing
>> > it
>> > >>> > take
>> > >>> > > >> form
>> > >>> > > >> > in
>> > >>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch
>> > (which
>> > >>> is
>> > >>> > for
>> > >>> > > >> > 0.6.0
>> > >>> > > >> > > >> at
>> > >>> > > >> > > >>>>>>> this point).
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>>> The proposal then for Git processes based on the
>> > other
>> > >>> > > thread
>> > >>> > > >> [1]
>> > >>> > > >> > > >>>>>>> where we outline a support model:
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>>> - 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
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>>> [1]
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>
>> > >>> > > >> > >
>> > >>> > > >> >
>> > >>> > > >>
>> > >>> > >
>> > >>> >
>> > >>>
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>>> Thanks
>> > >>> > > >> > > >>>>>>> Joe
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
>> > >>> > > joe.witt@gmail.com>
>> > >>> > > >> > > >> wrote:
>> > >>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
>> > >>> discuss
>> > >>> > > >> > specific
>> > >>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
>> > >>> consensus
>> > >>> > > >> > > discussion
>> > >>> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
>> > >>> kicked
>> > >>> > > off a
>> > >>> > > >> > > >>>>>>>> discussion back at that level.
>> > >>> > > >> > > >>>>>>>>
>> > >>> > > >> > > >>>>>>>>
>> > >>> > > >> > > >>>>>>>>
>> > >>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
>> > >>> > > trkurc@gmail.com>
>> > >>> > > >> > > >> wrote:
>> > >>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of
>> > the
>> > >>> > > plugins
>> > >>> > > >> > that
>> > >>> > > >> > > >> are
>> > >>> > > >> > > >>>>>>> used.
>> > >>> > > >> > > >>>>>>>>> I have worked on some other projects
>> > (unfortunately
>> > >>> not
>> > >>> > > open
>> > >>> > > >> > > >> source)
>> > >>> > > >> > > >>>>>>> that
>> > >>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever
>> > using
>> > >>> a
>> > >>> > > plugin.
>> > >>> > > >> > > Nice
>> > >>> > > >> > > >>>>> side
>> > >>> > > >> > > >>>>>>>>> effect is that I believe this got me better at
>> > using
>> > >>> > git,
>> > >>> > > and
>> > >>> > > >> > > >>>>> generally
>> > >>> > > >> > > >>>>>>> we
>> > >>> > > >> > > >>>>>>>>> all got better at managing merge pain.
>> > >>> > > >> > > >>>>>>>>>
>> > >>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're
>> > >>> operating
>> > >>> > the
>> > >>> > > way
>> > >>> > > >> > we
>> > >>> > > >> > > >> are
>> > >>> > > >> > > >>>>>>> now is
>> > >>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar
>> > for a
>> > >>> > > patch is
>> > >>> > > >> > > "can
>> > >>> > > >> > > >>> be
>> > >>> > > >> > > >>>>>>>>> merged into master", and we have our friend
>> Travis
>> > >>> to
>> > >>> > make
>> > >>> > > >> this
>> > >>> > > >> > > >> even
>> > >>> > > >> > > >>>>>>> easier
>> > >>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things.
>> > If
>> > >>> a
>> > >>> > > bugfix
>> > >>> > > >> is
>> > >>> > > >> > > >>>>> "patch
>> > >>> > > >> > > >>>>>>>>> needs to be able to apply onto the current
>> release
>> > >>> in
>> > >>> > > >> progress,
>> > >>> > > >> > > >>>>> master,
>> > >>> > > >> > > >>>>>>> and
>> > >>> > > >> > > >>>>>>>>> several other versions we're supporting, with
>> > >>> possibly
>> > >>> > > >> > > drastically
>> > >>> > > >> > > >>>>>>>>> different code", well then things get
>> interesting.
>> > >>> > > >> > > >>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>
>> > >>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson
>> > Margulies <
>> > >>> > > >> > > >>>>>>> bimargulies@gmail.com>
>> > >>> > > >> > > >>>>>>>>> wrote:
>> > >>> > > >> > > >>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>> The issue tracker
>> > >>> > > >> > > >>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>
>> > >>> > > >> > >
>> > >>> > > >> >
>> > >>> > > >>
>> > >>> > >
>> > >>> >
>> > >>>
>> >
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>> > >>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
>> > >>> > > >> > > >>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson
>> > Margulies
>> > >>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
>> > >>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin.
>> It
>> > >>> worked
>> > >>> > > >> great,
>> > >>> > > >> > > >>>>> until
>> > >>> > > >> > > >>>>>>> it
>> > >>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible,
>> > inexplicable,
>> > >>> > merge
>> > >>> > > >> > > >> problems.
>> > >>> > > >> > > >>>>> No
>> > >>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
>> > >>> > > >> > > >>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
>> > >>> > > >> > > >>>>>>>>>>>
>> > >>> > > >> >
>> https://github.com/egineering-llc/gitflow-helper-maven-plugin
>> > .
>> > >>> > > >> > > >>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
>> > >>> > > >> > adam@adamtaft.com
>> > >>> > > >> > > >
>> > >>> > > >> > > >>>>>>> wrote:
>> > >>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is
>> using
>> > >>> it in
>> > >>> > > >> > > >> combination
>> > >>> > > >> > > >>>>>>> with
>> > >>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases
>> > are
>> > >>> > > tracking
>> > >>> > > >> > > >>>>> closely
>> > >>> > > >> > > >>>>>>> with
>> > >>> > > >> > > >>>>>>>>>> the
>> > >>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
>> > >>> doesn't
>> > >>> > > keep
>> > >>> > > >> > the
>> > >>> > > >> > > >> pom
>> > >>> > > >> > > >>>>>>>>>> version
>> > >>> > > >> > > >>>>>>>>>>>> updated with the git release names.
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
>> > >>> releases
>> > >>> > > and
>> > >>> > > >> > tags
>> > >>> > > >> > > >>>>>>>>>> synchronized
>> > >>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do,
>> > it
>> > >>> > needs
>> > >>> > > to
>> > >>> > > >> be
>> > >>> > > >> > > >>>>>>> approached
>> > >>> > > >> > > >>>>>>>>>>>> with tools that are available through maven
>> > >>> rather
>> > >>> > than
>> > >>> > > >> from
>> > >>> > > >> > > >> git.
>> > >>> > > >> > > >>>>>>> The
>> > >>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
>> > >>> directly
>> > >>> > > help
>> > >>> > > >> > > deal
>> > >>> > > >> > > >>>>> with
>> > >>> > > >> > > >>>>>>>>>> this
>> > >>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a
>> > >>> maven
>> > >>> > > tool.
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
>> > >>> > jgitflow
>> > >>> > > [1]
>> > >>> > > >> > > >>>>> plugin,
>> > >>> > > >> > > >>>>>>> which
>> > >>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the
>> gitflow
>> > >>> model
>> > >>> > > for a
>> > >>> > > >> > > >> maven
>> > >>> > > >> > > >>>>>>>>>> project.
>> > >>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI,
>> because
>> > >>> it
>> > >>> > > insists
>> > >>> > > >> > > that
>> > >>> > > >> > > >>>>> the
>> > >>> > > >> > > >>>>>>>>>> master
>> > >>> > > >> > > >>>>>>>>>>>> branch is strictly used for published release
>> > >>> tags
>> > >>> > (as
>> > >>> > > per
>> > >>> > > >> > the
>> > >>> > > >> > > >>>>>>> strict
>> > >>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
>> > >>> reference
>> > >>> > > to
>> > >>> > > >> how
>> > >>> > > >> > > >> some
>> > >>> > > >> > > >>>>>>>>>> plugins
>> > >>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven
>> > >>> synchronization
>> > >>> > > issue.
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad
>> Guidry <
>> > >>> > > >> > > >>>>> thadguidry@gmail.com
>> > >>> > > >> > > >>>>>>>>
>> > >>> > > >> > > >>>>>>>>>> wrote:
>> > >>> > > >> > > >>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with
>> Git-flow.
>> > >>> Your
>> > >>> > > >> Master
>> > >>> > > >> > > >>>>> become
>> > >>> > > >> > > >>>>>>>>>> primary
>> > >>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
>> > >>> branches
>> > >>> > > off of
>> > >>> > > >> > > >> it)..
>> > >>> > > >> > > >>>>>>> while
>> > >>> > > >> > > >>>>>>>>>> you
>> > >>> > > >> > > >>>>>>>>>>>>> continue to have release branches that can
>> > have
>> > >>> hot
>> > >>> > > fix
>> > >>> > > >> > > >> branches
>> > >>> > > >> > > >>>>>>> off of
>> > >>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release
>> > branch
>> > >>> ! -
>> > >>> > > bad
>> > >>> > > >> > > >>>>> practice !
>> > >>> > > >> > > >>>>>>> )
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it
>> > >>> easy for
>> > >>> > > >> > everyone
>> > >>> > > >> > > >> to
>> > >>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain
>> the
>> > >>> > > >> > understanding.
>> > >>> > > >> > > >> Its
>> > >>> > > >> > > >>>>>>> really
>> > >>> > > >> > > >>>>>>>>>>>>> that easy.
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> http://danielkummer.github.io/git-flow-cheatsheet/
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
>> > >>> git-flow
>> > >>> > ...
>> > >>> > > >> and
>> > >>> > > >> > > >> tools
>> > >>> > > >> > > >>>>>>> like
>> > >>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree,
>> etc...have
>> > >>> > > Git-flow
>> > >>> > > >> > > either
>> > >>> > > >> > > >>>>>>> built
>> > >>> > > >> > > >>>>>>>>>> in or
>> > >>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live
>> on
>> > >>> the
>> > >>> > > command
>> > >>> > > >> > > >> line,
>> > >>> > > >> > > >>>>>>> then
>> > >>> > > >> > > >>>>>>>>>> that
>> > >>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the
>> > >>> above
>> > >>> > > link.
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>>>> Thad
>> > >>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <
>> > https://www.google.com/+ThadGuidry
>> > >>> >
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>
>> > >>> > > >> > >
>> > >>> > > >> > >
>> > >>> > > >> >
>> > >>> > > >>
>> > >>> > >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
To my knowledge, when you open a PR in GitHub it only allows the
contributor to select a single branch. The reviewer would need to check the
compatibility if that contribution needs to be applied to both. Depending
on the contribution, a separate PR may be required as the codebases
diverge. In practice though, most of the work on master (1.x) will focus on
the framework which is where diverging is most likely to occur.
Consequently, framework bug fixes are the most likely place where we may
need separate PRs.
On Mon, Apr 4, 2016 at 12:46 PM, Tony Kurc <tr...@gmail.com> wrote:
> Is travis ci / githib able to give immediate feedback if a PR doesn't merge
> into both?
>
> On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman <ma...@gmail.com>
> wrote:
>
> > All,
> >
> > I have completed the branching discussed last week.
> >
> > - master contains the current 1.x baseline - Future 1.x releases will
> start
> > from here
> > - 0.x contains the 0.x baseline - Future 0.x releases will start from
> here
> >
> > Going forward all PRs will need to be merged the either or both branches
> as
> > appropriate to ensure it's included in subsequent releases. I will be
> > updating the quick start and contributor guide to describe the
> distinction
> > between the two branches.
> >
> > Thanks!
> >
> > Matt
> >
> > On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <ma...@gmail.com>
> > wrote:
> >
> > > The majority consensus is to have master point to our 1.x baseline
> going
> > > forward. Unless there are any strong objections I will set everything
> up
> > on
> > > Monday (4/4) morning.
> > >
> > > - Create a 0.x branch for all future 0.x releases based on the current
> > > state of master.
> > > - Apply all 1.x commits from the temporary 1.x branch to master.
> > > - Delete the temporary 1.x branch.
> > > - Update the quickstart page and contribution guide to detail the
> > > distinction between the 0.x and master branches.
> > > - Send another email to @dev once this has been completed.
> > >
> > > Reminder: Going forward once this has been completed all commits will
> > need
> > > to be made to both branches as appropriate.
> > >
> > > Thanks!
> > >
> > > Matt
> > >
> > > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <ma...@gmail.com>
> > > wrote:
> > >
> > >> Matt,
> > >>
> > >> I agree that the PRs would need to be merged to both baselines at
> > >> contribution time. If the contribution applies cleanly the reviewer
> > could
> > >> certainly handle the commit themselves. However, if additional code
> > changes
> > >> are required because the baselines have diverged, the contributor
> would
> > >> probably need to submit another PR. This additional effort should only
> > be
> > >> necessary until we're able to perform the first 1.x release.
> > >>
> > >> Aldrin,
> > >>
> > >> I definitely understand your thoughts regarding (1) and (2). This is
> why
> > >> I wanted to pose the options before just jumping into one approach vs
> > the
> > >> other. I personally prefer the GitHub style PR process. I realize this
> > is
> > >> more cumbersome but hopefully the number of conflicts should be small
> as
> > >> folks are already starting to focus their efforts on the framework for
> > 1.x.
> > >>
> > >> Matt
> > >>
> > >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com>
> > >> wrote:
> > >>
> > >>> I think I prefer option 2 considering, what may be the incorrect
> > >>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be
> > easier.
> > >>> Based on outstanding PRs/Patches in conjunction with release cadence
> > >>> there
> > >>> will be more 0.x releases planned. Until we reached the point where
> the
> > >>> first 1.x release is in sight, I think (2) makes sense just from
> > >>> minimizing
> > >>> impedance where the majority of effort will occur (new/updated
> > >>> extensions)
> > >>> and then switching to (1) when we are scheduling 1.x as next
> (exclusive
> > >>> of
> > >>> any patch builds). This seems to work out when I try to reason about
> > it,
> > >>> but admittedly, am coming at this heavily from my own anecdotal
> > >>> perspective
> > >>> given my flow of reviewing.
> > >>>
> > >>> Matt, excellent points to consider.
> > >>>
> > >>> Do not want to go too much on a tangent from the current
> conversation,
> > >>> but
> > >>> I think we need to harness automation as much as possible. Not sure
> > >>> Travis
> > >>> can do this or do so easily (short of two PRs) and this may arguably
> > >>> shift
> > >>> things in favor of patches and the model that the other ASF projects
> > >>> utilize with buildbot. Getting as much done asynchronously for us is
> > >>> obviously important but we also have to strive to avoid a contrib
> > process
> > >>> that is too cumbersome as well.
> > >>>
> > >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > I like option 1 as well.
> > >>> >
> > >>> > In the case where a fix is to be put into both branches, will the
> > >>> developer
> > >>> > be responsible for issuing 2 PRs / patches, one against each
> branch?
> > >>> This
> > >>> > would help in the case that the PR/patch against 0.x won't merge
> > >>> cleanly
> > >>> > into master; however the reviewer(s) would need to make sure there
> > >>> were no
> > >>> > breaking changes as a result of the manual merge to master. An
> > >>> alternative
> > >>> > is that the reviewer(s) do the forward-port, which I don't think
> is a
> > >>> good
> > >>> > idea. However the reviewer would need to make sure the PR(s) are
> > >>> against
> > >>> > the correct branch. For example, all current PRs would need to be
> > >>> > "backported" to the new 0.x branch.
> > >>> >
> > >>> > Also, I would think the PRs/patches need to be merged at the same
> > time
> > >>> (or
> > >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but
> > getting
> > >>> > forgotten/missed for 1.x).
> > >>> >
> > >>> > Thoughts? Thanks,
> > >>> > Matt
> > >>> >
> > >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com>
> > wrote:
> > >>> >
> > >>> > > I too prefer option 1
> > >>> > >
> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu>
> > >>> wrote:
> > >>> > > > I agree with Tony on option 1. I think it makes sense for
> > master
> > >>> to
> > >>> > be
> > >>> > > > the most "advanced" branch. New features will then always be
> > >>> applied
> > >>> > to
> > >>> > > > master, and optionally to other branches for older version
> > support
> > >>> as
> > >>> > > > applicable / desired.
> > >>> > > >
> > >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com>
> > >>> wrote:
> > >>> > > >
> > >>> > > >> I like option 1
> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <
> > matt.c.gilman@gmail.com>
> > >>> > > wrote:
> > >>> > > >>
> > >>> > > >> > Hello,
> > >>> > > >> >
> > >>> > > >> > With NiFi 0.6.0 officially released and our support strategy
> > >>> defined
> > >>> > > [1],
> > >>> > > >> > I'd like to revisit and propose some options for supporting
> > >>> both a
> > >>> > 1.x
> > >>> > > >> > branch and 0.x branch concurrently. We need an official
> place
> > >>> where
> > >>> > > these
> > >>> > > >> > efforts can be worked, contributed to, and collaborated with
> > the
> > >>> > > >> community.
> > >>> > > >> > I've already created a 1.x branch as a temporary place for
> > this
> > >>> > > codebase
> > >>> > > >> to
> > >>> > > >> > live until we agree to an approach.
> > >>> > > >> >
> > >>> > > >> > Either option I'm proposing will require
> > >>> PRs/contributions/patches
> > >>> > to
> > >>> > > be
> > >>> > > >> > applied to both branches as applicable. This means that the
> > >>> > > contributor
> > >>> > > >> or
> > >>> > > >> > the reviewer will need to be able to apply the commits in
> both
> > >>> > places
> > >>> > > if
> > >>> > > >> > it's necessary. For instance, framework code has already
> > started
> > >>> > > >> diverging
> > >>> > > >> > from the current master so any framework change may not need
> > to
> > >>> be
> > >>> > > >> applied
> > >>> > > >> > to both if the changeset is not applicable to the 1.x
> > baseline.
> > >>> > > >> >
> > >>> > > >> > The only question at the moment is what master will refer
> to.
> > >>> > > >> >
> > >>> > > >> > 1) Create a branch for 0.x and allow master to become the
> 1.x
> > >>> > baseline
> > >>> > > >> > going forward. Future 0.x releases will be performed from
> the
> > >>> 0.x
> > >>> > > branch.
> > >>> > > >> > 2) Continuing working on the 1.x branch as is. Allow master
> to
> > >>> > > continue
> > >>> > > >> to
> > >>> > > >> > servicing 0.x releases. Once a 1.x release is made, create
> the
> > >>> 0.x
> > >>> > > branch
> > >>> > > >> > and then allow master to service 1.x releases.
> > >>> > > >> >
> > >>> > > >> > In short, when do we want master to point to the 1.x
> baseline?
> > >>> When
> > >>> > > >> should
> > >>> > > >> > we create a branch where 0.x releases will be made from.
> > >>> Regardless,
> > >>> > > >> > contributions will need to be performed to both places as
> > >>> > applicable.
> > >>> > > >> >
> > >>> > > >> > Thanks.
> > >>> > > >> >
> > >>> > > >> > Matt
> > >>> > > >> >
> > >>> > > >> > [1]
> > >>> > > >> >
> > >>> > > >> >
> > >>> > > >>
> > >>> > >
> > >>> >
> > >>>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >>> > > >> >
> > >>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> > >>> > > r.p.miskin@gmail.com>
> > >>> > > >> > wrote:
> > >>> > > >> >
> > >>> > > >> > > I guess it will depend how much change is expected on the
> > >>> > > maintenance
> > >>> > > >> > > branches,
> > >>> > > >> > > but if you want every change in the maintenance branch to
> go
> > >>> into
> > >>> > > the
> > >>> > > >> > > main-line branch then there is little difference from a
> > >>> conflict
> > >>> > > point
> > >>> > > >> of
> > >>> > > >> > > view
> > >>> > > >> > > between a series of cherry-picks and a merge.
> > >>> > > >> > >
> > >>> > > >> > > Either way, it is just another approach to consider.
> There’s
> > >>> more
> > >>> > > than
> > >>> > > >> > one
> > >>> > > >> > > way to do it, and I suspect there isn’t any solution that
> > >>> makes it
> > >>> > > >> > trivial.
> > >>> > > >> > >
> > >>> > > >> > > Cheers,
> > >>> > > >> > > Richard
> > >>> > > >> > >
> > >>> > > >> > >
> > >>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <
> > aldrinpiri@gmail.com
> > >>> >
> > >>> > > wrote:
> > >>> > > >> > > >
> > >>> > > >> > > > On board with Tony's points. I think the realities of
> > >>> merging
> > >>> > in
> > >>> > > >> > > practice
> > >>> > > >> > > > when that "breaking point" of sorts occurs will make the
> > >>> > > complexity
> > >>> > > >> and
> > >>> > > >> > > > overhead quite difficult and maybe even more error prone
> > >>> than
> > >>> > the
> > >>> > > >> > cherry
> > >>> > > >> > > > picking approach with some additional guidelines. When
> > the
> > >>> > > codebase
> > >>> > > >> > > > drastically changes, the merge conflicts could be quite
> > >>> severe
> > >>> > and
> > >>> > > >> > > without
> > >>> > > >> > > > a good knowledge of each part of the codebase involved
> > >>> during
> > >>> > that
> > >>> > > >> > > process,
> > >>> > > >> > > > a committer may introduce regressions.
> > >>> > > >> > > >
> > >>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <
> > >>> trkurc@gmail.com>
> > >>> > > wrote:
> > >>> > > >> > > >
> > >>> > > >> > > >> the reason I like applying patches to both lines is
> that
> > >>> once
> > >>> > > code
> > >>> > > >> > > begins
> > >>> > > >> > > >> to diverge, cleanly merging into one codebase can be
> > >>> > impossible.
> > >>> > > >> > having
> > >>> > > >> > > >> good practices for managing patches and where they
> apply
> > is
> > >>> > > >> paramount
> > >>> > > >> > > for
> > >>> > > >> > > >> success.
> > >>> > > >> > > >>
> > >>> > > >> > > >> I expect that divergence to happen with 1.x. I wanted
> to
> > >>> get
> > >>> > in a
> > >>> > > >> > battle
> > >>> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
> > >>> patches
> > >>> > > >> COULD
> > >>> > > >> > be
> > >>> > > >> > > >> applied to both in the manner you described.
> > >>> > > >> > > >>
> > >>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
> > >>> tickets
> > >>> > > >> marked
> > >>> > > >> > > for
> > >>> > > >> > > >> 0.5.1 had the right patches in the support branch, and
> > some
> > >>> > > didn't,
> > >>> > > >> > so I
> > >>> > > >> > > >> think "lesson learned". I do like in the apache
> > >>> infrastructure
> > >>> > > that
> > >>> > > >> if
> > >>> > > >> > > >> commits have the appropriate ticket in their commit
> > >>> message,
> > >>> > the
> > >>> > > >> jira
> > >>> > > >> > > will
> > >>> > > >> > > >> have the list of commits and branches those commits
> were
> > >>> > applies
> > >>> > > to.
> > >>> > > >> > > >> However, I think we may need to revisit commit message
> > >>> > > "hygiene" if
> > >>> > > >> > we
> > >>> > > >> > > >> relied on this instead of more manual review.
> > >>> > > >> > > >>
> > >>> > > >> > > >>
> > >>> > > >> > > >>
> > >>> > > >> > > >>
> > >>> > > >> > > >>
> > >>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> > >>> > > >> r.p.miskin@gmail.com
> > >>> > > >> > >
> > >>> > > >> > > >> wrote:
> > >>> > > >> > > >>
> > >>> > > >> > > >>> Hi,
> > >>> > > >> > > >>>
> > >>> > > >> > > >>> On a couple of work projects we found that the
> approach
> > of
> > >>> > > >> > > cherry-picking
> > >>> > > >> > > >>> commits can lead to an unnecessarily complicated
> history
> > >>> where
> > >>> > > the
> > >>> > > >> > same
> > >>> > > >> > > >>> piece of work appears as multiple separate commits on
> > >>> > different
> > >>> > > >> > > branches.
> > >>> > > >> > > >>> This can then make it hard to be confident that a bug
> > fix
> > >>> has
> > >>> > > been
> > >>> > > >> > > >> applied
> > >>> > > >> > > >>> to all relevant branches. We found that it works
> better
> > >>> to aim
> > >>> > > to
> > >>> > > >> > > commit
> > >>> > > >> > > >>> changes to the lowest applicable branch, and then
> > >>> regularly
> > >>> > > merge
> > >>> > > >> > those
> > >>> > > >> > > >>> branches to master. This approach is based on the
> > git-flow
> > >>> > > model (
> > >>> > > >> > > >>>
> http://nvie.com/posts/a-successful-git-branching-model/
> > <
> > >>> > > >> > > >>>
> http://nvie.com/posts/a-successful-git-branching-model/
> > >>> >).
> > >>> > > >> > > >>>
> > >>> > > >> > > >>> Looking at the repo there are already a few commits
> that
> > >>> are
> > >>> > > >> > duplicated
> > >>> > > >> > > >> on
> > >>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d
> only
> > >>> occur
> > >>> > on
> > >>> > > >> > 0.5.1,
> > >>> > > >> > > >> and
> > >>> > > >> > > >>> then that branch would get merged to master.
> > >>> > > >> > > >>>
> > >>> > > >> > > >>> Having the merge commits from the support branch to
> > master
> > >>> > > makes it
> > >>> > > >> > > >>> explicit in the git history that all bug fixes (and
> > >>> associated
> > >>> > > >> tests)
> > >>> > > >> > > >> have
> > >>> > > >> > > >>> been pulled through to master.
> > >>> > > >> > > >>>
> > >>> > > >> > > >>> Cheers,
> > >>> > > >> > > >>> Richard
> > >>> > > >> > > >>>
> > >>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <
> jvwing@gmail.com
> > >
> > >>> > wrote:
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and
> > >>> see if
> > >>> > > you
> > >>> > > >> > > agree:
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> 1.) Commits merged to master today are destined for
> the
> > >>> next
> > >>> > > minor
> > >>> > > >> > > >>> release,
> > >>> > > >> > > >>>> currently 0.6.0, by default?
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> By default, commits to master will be released in the
> > >>> next
> > >>> > > major
> > >>> > > >> or
> > >>> > > >> > > >> minor
> > >>> > > >> > > >>>> release. No commits are included in
> incremental/patch
> > >>> > > releases by
> > >>> > > >> > > >>> default.
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> support/0.5.x will be maintained until the first of
> the
> > >>> > > following
> > >>> > > >> > > >> events:
> > >>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major
> > >>> release
> > >>> > > line)
> > >>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
> > >>> release
> > >>> > > >> lines
> > >>> > > >> > up
> > >>> > > >> > > >> to
> > >>> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y)
> in
> > >>> that
> > >>> > > >> line")
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> But additional support might be available by special
> > >>> request.
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined
> for a
> > >>> > future
> > >>> > > >> major
> > >>> > > >> > > >>>> release stored? Is it visible anywhere?
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> I suppose Jira tickets targeting the next major
> release
> > >>> > > >> > > >>> could/should/would
> > >>> > > >> > > >>>> (do?) push branches. That seems weak in the face of
> a
> > >>> > probable
> > >>> > > >> > > >> stampede
> > >>> > > >> > > >>>> towards the fire exit of a major release, but it's a
> > >>> start.
> > >>> > > I'm
> > >>> > > >> not
> > >>> > > >> > > >>> aware
> > >>> > > >> > > >>>> of any great solutions here, certainly not for an
> > >>> open-source
> > >>> > > >> > project.
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
> > >>> > joe.witt@gmail.com>
> > >>> > > >> > wrote:
> > >>> > > >> > > >>>>
> > >>> > > >> > > >>>>> James,
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> These are great questions to frame and test the
> model.
> > >>> So
> > >>> > > let's
> > >>> > > >> > > >>>>> attempt to address them agains the model.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> Here is the language for that model at this time:
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> - 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'
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> So with those above let's review 1 through 5 in
> turn.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> 1.) Commits merged to master today are destined for
> > the
> > >>> next
> > >>> > > >> minor
> > >>> > > >> > > >>>>> release, currently 0.6.0, by default?
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> Master is for whatever is the most leading edge
> > release
> > >>> line
> > >>> > > >> > working
> > >>> > > >> > > >>>>> toward the next release. At the time that a minor
> > >>> release
> > >>> > > occurs
> > >>> > > >> > > >>>>> against that release line then it branches off into
> a
> > >>> > > >> support/x.y.*
> > >>> > > >> > > >>>>> branch for any further efforts against it.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> 2.) Is master always open for merging new code, or
> are
> > >>> there
> > >>> > > >> > > >>> restrictions
> > >>> > > >> > > >>>>> before or after releases?
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> I believe master would be always open for new code.
> > >>> From
> > >>> > some
> > >>> > > >> > point
> > >>> > > >> > > >>>>> at which a release is considered feature complete
> then
> > >>> > further
> > >>> > > >> > > feature
> > >>> > > >> > > >>>>> enhancements need to go on master as part of the
> next
> > >>> > release
> > >>> > > >> > effort.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> The most recent minor release line of a major line
> > will
> > >>> be
> > >>> > > >> > supported
> > >>> > > >> > > >>>>> for up to one year from whenever it was released
> where
> > >>> > > support is
> > >>> > > >> > for
> > >>> > > >> > > >>>>> bug fixes for security or data loss related items.
> > >>> Releases
> > >>> > > for
> > >>> > > >> > > older
> > >>> > > >> > > >>>>> minor lines should be considered on a case by case
> > >>> basis and
> > >>> > > if
> > >>> > > >> > > >>>>> requested. Otherwise the basic premise is the train
> > is
> > >>> > moving
> > >>> > > >> > > >>>>> forward.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined
> for
> > a
> > >>> > future
> > >>> > > >> > major
> > >>> > > >> > > >>>>> release stored? Is it visible anywhere?
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> It must be visible. It should be placed into a
> branch
> > >>> until
> > >>> > > such
> > >>> > > >> > > >>>>> time that it is ready to become the new master.
> That
> > >>> time
> > >>> > > would
> > >>> > > >> be
> > >>> > > >> > > >>>>> when the next release will be for that line. When I
> > >>> think
> > >>> > > about
> > >>> > > >> > this
> > >>> > > >> > > >>>>> against the stated model we could probably tweak the
> > >>> wording
> > >>> > > to
> > >>> > > >> > > better
> > >>> > > >> > > >>>>> articulate that. I think it was what was meant with
> > >>> 'when
> > >>> > > master
> > >>> > > >> > has
> > >>> > > >> > > >>>>> no releases we will backport...' but that is
> unclear.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0
> would
> > >>> > > eligible
> > >>> > > >> to
> > >>> > > >> > be
> > >>> > > >> > > >>>>> backported only to the last minor release in the 0.x
> > >>> line,
> > >>> > or
> > >>> > > to
> > >>> > > >> > all
> > >>> > > >> > > >>> minor
> > >>> > > >> > > >>>>> releases in the 0.x line?
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> Only to the most recent minor release of any still
> > >>> supported
> > >>> > > >> major
> > >>> > > >> > > >>>>> line. However, the catch of 'case by case'
> > >>> determination
> > >>> > for
> > >>> > > >> older
> > >>> > > >> > > >>>>> minor lines is still in play. Basically if someone
> > >>> requests
> > >>> > > it
> > >>> > > >> and
> > >>> > > >> > > >>>>> can get enough momentum for it then it should be no
> > >>> problem
> > >>> > to
> > >>> > > >> > > produce
> > >>> > > >> > > >>>>> such a release.
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> Thanks
> > >>> > > >> > > >>>>> Joe
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
> > >>> > jvwing@gmail.com
> > >>> > > >
> > >>> > > >> > > wrote:
> > >>> > > >> > > >>>>>> I have some rhetorical questions for discussion of
> > the
> > >>> > > branching
> > >>> > > >> > > >> model:
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> 1.) Commits merged to master today are destined for
> > the
> > >>> > next
> > >>> > > >> minor
> > >>> > > >> > > >>>>> release,
> > >>> > > >> > > >>>>>> currently 0.6.0, by default?
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> 2.) Is master always open for merging new code, or
> > are
> > >>> > there
> > >>> > > >> > > >>> restrictions
> > >>> > > >> > > >>>>>> before or after releases?
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined
> > for a
> > >>> > > future
> > >>> > > >> > major
> > >>> > > >> > > >>>>>> release stored? Is it visible anywhere?
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0
> > would
> > >>> > > eligible
> > >>> > > >> to
> > >>> > > >> > > be
> > >>> > > >> > > >>>>>> backported only to the last minor release in the
> 0.x
> > >>> line,
> > >>> > > or to
> > >>> > > >> > all
> > >>> > > >> > > >>>>> minor
> > >>> > > >> > > >>>>>> releases in the 0.x line?
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> > >>> > > joe.witt@gmail.com>
> > >>> > > >> > > >> wrote:
> > >>> > > >> > > >>>>>>
> > >>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn
> it
> > >>> more
> > >>> > > >> toward
> > >>> > > >> > a
> > >>> > > >> > > >>>>>>> proposal as we're at a point now where we need to
> > >>> start
> > >>> > > >> executing
> > >>> > > >> > > >> some
> > >>> > > >> > > >>>>>>> of these approaches. We're actually already
> seeing
> > it
> > >>> > take
> > >>> > > >> form
> > >>> > > >> > in
> > >>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch
> > (which
> > >>> is
> > >>> > for
> > >>> > > >> > 0.6.0
> > >>> > > >> > > >> at
> > >>> > > >> > > >>>>>>> this point).
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>>> The proposal then for Git processes based on the
> > other
> > >>> > > thread
> > >>> > > >> [1]
> > >>> > > >> > > >>>>>>> where we outline a support model:
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>>> - 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
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>>> [1]
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>
> > >>> > > >> > > >>
> > >>> > > >> > >
> > >>> > > >> >
> > >>> > > >>
> > >>> > >
> > >>> >
> > >>>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>>> Thanks
> > >>> > > >> > > >>>>>>> Joe
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> > >>> > > joe.witt@gmail.com>
> > >>> > > >> > > >> wrote:
> > >>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
> > >>> discuss
> > >>> > > >> > specific
> > >>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
> > >>> consensus
> > >>> > > >> > > discussion
> > >>> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
> > >>> kicked
> > >>> > > off a
> > >>> > > >> > > >>>>>>>> discussion back at that level.
> > >>> > > >> > > >>>>>>>>
> > >>> > > >> > > >>>>>>>>
> > >>> > > >> > > >>>>>>>>
> > >>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> > >>> > > trkurc@gmail.com>
> > >>> > > >> > > >> wrote:
> > >>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of
> > the
> > >>> > > plugins
> > >>> > > >> > that
> > >>> > > >> > > >> are
> > >>> > > >> > > >>>>>>> used.
> > >>> > > >> > > >>>>>>>>> I have worked on some other projects
> > (unfortunately
> > >>> not
> > >>> > > open
> > >>> > > >> > > >> source)
> > >>> > > >> > > >>>>>>> that
> > >>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever
> > using
> > >>> a
> > >>> > > plugin.
> > >>> > > >> > > Nice
> > >>> > > >> > > >>>>> side
> > >>> > > >> > > >>>>>>>>> effect is that I believe this got me better at
> > using
> > >>> > git,
> > >>> > > and
> > >>> > > >> > > >>>>> generally
> > >>> > > >> > > >>>>>>> we
> > >>> > > >> > > >>>>>>>>> all got better at managing merge pain.
> > >>> > > >> > > >>>>>>>>>
> > >>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're
> > >>> operating
> > >>> > the
> > >>> > > way
> > >>> > > >> > we
> > >>> > > >> > > >> are
> > >>> > > >> > > >>>>>>> now is
> > >>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar
> > for a
> > >>> > > patch is
> > >>> > > >> > > "can
> > >>> > > >> > > >>> be
> > >>> > > >> > > >>>>>>>>> merged into master", and we have our friend
> Travis
> > >>> to
> > >>> > make
> > >>> > > >> this
> > >>> > > >> > > >> even
> > >>> > > >> > > >>>>>>> easier
> > >>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things.
> > If
> > >>> a
> > >>> > > bugfix
> > >>> > > >> is
> > >>> > > >> > > >>>>> "patch
> > >>> > > >> > > >>>>>>>>> needs to be able to apply onto the current
> release
> > >>> in
> > >>> > > >> progress,
> > >>> > > >> > > >>>>> master,
> > >>> > > >> > > >>>>>>> and
> > >>> > > >> > > >>>>>>>>> several other versions we're supporting, with
> > >>> possibly
> > >>> > > >> > > drastically
> > >>> > > >> > > >>>>>>>>> different code", well then things get
> interesting.
> > >>> > > >> > > >>>>>>>>>
> > >>> > > >> > > >>>>>>>>>
> > >>> > > >> > > >>>>>>>>>
> > >>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson
> > Margulies <
> > >>> > > >> > > >>>>>>> bimargulies@gmail.com>
> > >>> > > >> > > >>>>>>>>> wrote:
> > >>> > > >> > > >>>>>>>>>
> > >>> > > >> > > >>>>>>>>>> The issue tracker
> > >>> > > >> > > >>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>
> > >>> > > >> > > >>
> > >>> > > >> > >
> > >>> > > >> >
> > >>> > > >>
> > >>> > >
> > >>> >
> > >>>
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > >>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
> > >>> > > >> > > >>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson
> > Margulies
> > >>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> > >>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin.
> It
> > >>> worked
> > >>> > > >> great,
> > >>> > > >> > > >>>>> until
> > >>> > > >> > > >>>>>>> it
> > >>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible,
> > inexplicable,
> > >>> > merge
> > >>> > > >> > > >> problems.
> > >>> > > >> > > >>>>> No
> > >>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
> > >>> > > >> > > >>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
> > >>> > > >> > > >>>>>>>>>>>
> > >>> > > >> >
> https://github.com/egineering-llc/gitflow-helper-maven-plugin
> > .
> > >>> > > >> > > >>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> > >>> > > >> > adam@adamtaft.com
> > >>> > > >> > > >
> > >>> > > >> > > >>>>>>> wrote:
> > >>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is
> using
> > >>> it in
> > >>> > > >> > > >> combination
> > >>> > > >> > > >>>>>>> with
> > >>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases
> > are
> > >>> > > tracking
> > >>> > > >> > > >>>>> closely
> > >>> > > >> > > >>>>>>> with
> > >>> > > >> > > >>>>>>>>>> the
> > >>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
> > >>> doesn't
> > >>> > > keep
> > >>> > > >> > the
> > >>> > > >> > > >> pom
> > >>> > > >> > > >>>>>>>>>> version
> > >>> > > >> > > >>>>>>>>>>>> updated with the git release names.
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
> > >>> releases
> > >>> > > and
> > >>> > > >> > tags
> > >>> > > >> > > >>>>>>>>>> synchronized
> > >>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do,
> > it
> > >>> > needs
> > >>> > > to
> > >>> > > >> be
> > >>> > > >> > > >>>>>>> approached
> > >>> > > >> > > >>>>>>>>>>>> with tools that are available through maven
> > >>> rather
> > >>> > than
> > >>> > > >> from
> > >>> > > >> > > >> git.
> > >>> > > >> > > >>>>>>> The
> > >>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
> > >>> directly
> > >>> > > help
> > >>> > > >> > > deal
> > >>> > > >> > > >>>>> with
> > >>> > > >> > > >>>>>>>>>> this
> > >>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a
> > >>> maven
> > >>> > > tool.
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
> > >>> > jgitflow
> > >>> > > [1]
> > >>> > > >> > > >>>>> plugin,
> > >>> > > >> > > >>>>>>> which
> > >>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the
> gitflow
> > >>> model
> > >>> > > for a
> > >>> > > >> > > >> maven
> > >>> > > >> > > >>>>>>>>>> project.
> > >>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI,
> because
> > >>> it
> > >>> > > insists
> > >>> > > >> > > that
> > >>> > > >> > > >>>>> the
> > >>> > > >> > > >>>>>>>>>> master
> > >>> > > >> > > >>>>>>>>>>>> branch is strictly used for published release
> > >>> tags
> > >>> > (as
> > >>> > > per
> > >>> > > >> > the
> > >>> > > >> > > >>>>>>> strict
> > >>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
> > >>> reference
> > >>> > > to
> > >>> > > >> how
> > >>> > > >> > > >> some
> > >>> > > >> > > >>>>>>>>>> plugins
> > >>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven
> > >>> synchronization
> > >>> > > issue.
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad
> Guidry <
> > >>> > > >> > > >>>>> thadguidry@gmail.com
> > >>> > > >> > > >>>>>>>>
> > >>> > > >> > > >>>>>>>>>> wrote:
> > >>> > > >> > > >>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with
> Git-flow.
> > >>> Your
> > >>> > > >> Master
> > >>> > > >> > > >>>>> become
> > >>> > > >> > > >>>>>>>>>> primary
> > >>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
> > >>> branches
> > >>> > > off of
> > >>> > > >> > > >> it)..
> > >>> > > >> > > >>>>>>> while
> > >>> > > >> > > >>>>>>>>>> you
> > >>> > > >> > > >>>>>>>>>>>>> continue to have release branches that can
> > have
> > >>> hot
> > >>> > > fix
> > >>> > > >> > > >> branches
> > >>> > > >> > > >>>>>>> off of
> > >>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release
> > branch
> > >>> ! -
> > >>> > > bad
> > >>> > > >> > > >>>>> practice !
> > >>> > > >> > > >>>>>>> )
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it
> > >>> easy for
> > >>> > > >> > everyone
> > >>> > > >> > > >> to
> > >>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain
> the
> > >>> > > >> > understanding.
> > >>> > > >> > > >> Its
> > >>> > > >> > > >>>>>>> really
> > >>> > > >> > > >>>>>>>>>>>>> that easy.
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> http://danielkummer.github.io/git-flow-cheatsheet/
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
> > >>> git-flow
> > >>> > ...
> > >>> > > >> and
> > >>> > > >> > > >> tools
> > >>> > > >> > > >>>>>>> like
> > >>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree,
> etc...have
> > >>> > > Git-flow
> > >>> > > >> > > either
> > >>> > > >> > > >>>>>>> built
> > >>> > > >> > > >>>>>>>>>> in or
> > >>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live
> on
> > >>> the
> > >>> > > command
> > >>> > > >> > > >> line,
> > >>> > > >> > > >>>>>>> then
> > >>> > > >> > > >>>>>>>>>> that
> > >>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the
> > >>> above
> > >>> > > link.
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>>>> Thad
> > >>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <
> > https://www.google.com/+ThadGuidry
> > >>> >
> > >>> > > >> > > >>>>>>>>>>>>>
> > >>> > > >> > > >>>>>>>>>>
> > >>> > > >> > > >>>>>>>
> > >>> > > >> > > >>>>>
> > >>> > > >> > > >>>
> > >>> > > >> > > >>>
> > >>> > > >> > > >>
> > >>> > > >> > >
> > >>> > > >> > >
> > >>> > > >> >
> > >>> > > >>
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
Is travis ci / githib able to give immediate feedback if a PR doesn't merge
into both?
On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman <ma...@gmail.com>
wrote:
> All,
>
> I have completed the branching discussed last week.
>
> - master contains the current 1.x baseline - Future 1.x releases will start
> from here
> - 0.x contains the 0.x baseline - Future 0.x releases will start from here
>
> Going forward all PRs will need to be merged the either or both branches as
> appropriate to ensure it's included in subsequent releases. I will be
> updating the quick start and contributor guide to describe the distinction
> between the two branches.
>
> Thanks!
>
> Matt
>
> On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <ma...@gmail.com>
> wrote:
>
> > The majority consensus is to have master point to our 1.x baseline going
> > forward. Unless there are any strong objections I will set everything up
> on
> > Monday (4/4) morning.
> >
> > - Create a 0.x branch for all future 0.x releases based on the current
> > state of master.
> > - Apply all 1.x commits from the temporary 1.x branch to master.
> > - Delete the temporary 1.x branch.
> > - Update the quickstart page and contribution guide to detail the
> > distinction between the 0.x and master branches.
> > - Send another email to @dev once this has been completed.
> >
> > Reminder: Going forward once this has been completed all commits will
> need
> > to be made to both branches as appropriate.
> >
> > Thanks!
> >
> > Matt
> >
> > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <ma...@gmail.com>
> > wrote:
> >
> >> Matt,
> >>
> >> I agree that the PRs would need to be merged to both baselines at
> >> contribution time. If the contribution applies cleanly the reviewer
> could
> >> certainly handle the commit themselves. However, if additional code
> changes
> >> are required because the baselines have diverged, the contributor would
> >> probably need to submit another PR. This additional effort should only
> be
> >> necessary until we're able to perform the first 1.x release.
> >>
> >> Aldrin,
> >>
> >> I definitely understand your thoughts regarding (1) and (2). This is why
> >> I wanted to pose the options before just jumping into one approach vs
> the
> >> other. I personally prefer the GitHub style PR process. I realize this
> is
> >> more cumbersome but hopefully the number of conflicts should be small as
> >> folks are already starting to focus their efforts on the framework for
> 1.x.
> >>
> >> Matt
> >>
> >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com>
> >> wrote:
> >>
> >>> I think I prefer option 2 considering, what may be the incorrect
> >>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be
> easier.
> >>> Based on outstanding PRs/Patches in conjunction with release cadence
> >>> there
> >>> will be more 0.x releases planned. Until we reached the point where the
> >>> first 1.x release is in sight, I think (2) makes sense just from
> >>> minimizing
> >>> impedance where the majority of effort will occur (new/updated
> >>> extensions)
> >>> and then switching to (1) when we are scheduling 1.x as next (exclusive
> >>> of
> >>> any patch builds). This seems to work out when I try to reason about
> it,
> >>> but admittedly, am coming at this heavily from my own anecdotal
> >>> perspective
> >>> given my flow of reviewing.
> >>>
> >>> Matt, excellent points to consider.
> >>>
> >>> Do not want to go too much on a tangent from the current conversation,
> >>> but
> >>> I think we need to harness automation as much as possible. Not sure
> >>> Travis
> >>> can do this or do so easily (short of two PRs) and this may arguably
> >>> shift
> >>> things in favor of patches and the model that the other ASF projects
> >>> utilize with buildbot. Getting as much done asynchronously for us is
> >>> obviously important but we also have to strive to avoid a contrib
> process
> >>> that is too cumbersome as well.
> >>>
> >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
> >>> wrote:
> >>>
> >>> > I like option 1 as well.
> >>> >
> >>> > In the case where a fix is to be put into both branches, will the
> >>> developer
> >>> > be responsible for issuing 2 PRs / patches, one against each branch?
> >>> This
> >>> > would help in the case that the PR/patch against 0.x won't merge
> >>> cleanly
> >>> > into master; however the reviewer(s) would need to make sure there
> >>> were no
> >>> > breaking changes as a result of the manual merge to master. An
> >>> alternative
> >>> > is that the reviewer(s) do the forward-port, which I don't think is a
> >>> good
> >>> > idea. However the reviewer would need to make sure the PR(s) are
> >>> against
> >>> > the correct branch. For example, all current PRs would need to be
> >>> > "backported" to the new 0.x branch.
> >>> >
> >>> > Also, I would think the PRs/patches need to be merged at the same
> time
> >>> (or
> >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but
> getting
> >>> > forgotten/missed for 1.x).
> >>> >
> >>> > Thoughts? Thanks,
> >>> > Matt
> >>> >
> >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com>
> wrote:
> >>> >
> >>> > > I too prefer option 1
> >>> > >
> >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu>
> >>> wrote:
> >>> > > > I agree with Tony on option 1. I think it makes sense for
> master
> >>> to
> >>> > be
> >>> > > > the most "advanced" branch. New features will then always be
> >>> applied
> >>> > to
> >>> > > > master, and optionally to other branches for older version
> support
> >>> as
> >>> > > > applicable / desired.
> >>> > > >
> >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com>
> >>> wrote:
> >>> > > >
> >>> > > >> I like option 1
> >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <
> matt.c.gilman@gmail.com>
> >>> > > wrote:
> >>> > > >>
> >>> > > >> > Hello,
> >>> > > >> >
> >>> > > >> > With NiFi 0.6.0 officially released and our support strategy
> >>> defined
> >>> > > [1],
> >>> > > >> > I'd like to revisit and propose some options for supporting
> >>> both a
> >>> > 1.x
> >>> > > >> > branch and 0.x branch concurrently. We need an official place
> >>> where
> >>> > > these
> >>> > > >> > efforts can be worked, contributed to, and collaborated with
> the
> >>> > > >> community.
> >>> > > >> > I've already created a 1.x branch as a temporary place for
> this
> >>> > > codebase
> >>> > > >> to
> >>> > > >> > live until we agree to an approach.
> >>> > > >> >
> >>> > > >> > Either option I'm proposing will require
> >>> PRs/contributions/patches
> >>> > to
> >>> > > be
> >>> > > >> > applied to both branches as applicable. This means that the
> >>> > > contributor
> >>> > > >> or
> >>> > > >> > the reviewer will need to be able to apply the commits in both
> >>> > places
> >>> > > if
> >>> > > >> > it's necessary. For instance, framework code has already
> started
> >>> > > >> diverging
> >>> > > >> > from the current master so any framework change may not need
> to
> >>> be
> >>> > > >> applied
> >>> > > >> > to both if the changeset is not applicable to the 1.x
> baseline.
> >>> > > >> >
> >>> > > >> > The only question at the moment is what master will refer to.
> >>> > > >> >
> >>> > > >> > 1) Create a branch for 0.x and allow master to become the 1.x
> >>> > baseline
> >>> > > >> > going forward. Future 0.x releases will be performed from the
> >>> 0.x
> >>> > > branch.
> >>> > > >> > 2) Continuing working on the 1.x branch as is. Allow master to
> >>> > > continue
> >>> > > >> to
> >>> > > >> > servicing 0.x releases. Once a 1.x release is made, create the
> >>> 0.x
> >>> > > branch
> >>> > > >> > and then allow master to service 1.x releases.
> >>> > > >> >
> >>> > > >> > In short, when do we want master to point to the 1.x baseline?
> >>> When
> >>> > > >> should
> >>> > > >> > we create a branch where 0.x releases will be made from.
> >>> Regardless,
> >>> > > >> > contributions will need to be performed to both places as
> >>> > applicable.
> >>> > > >> >
> >>> > > >> > Thanks.
> >>> > > >> >
> >>> > > >> > Matt
> >>> > > >> >
> >>> > > >> > [1]
> >>> > > >> >
> >>> > > >> >
> >>> > > >>
> >>> > >
> >>> >
> >>>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >>> > > >> >
> >>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> >>> > > r.p.miskin@gmail.com>
> >>> > > >> > wrote:
> >>> > > >> >
> >>> > > >> > > I guess it will depend how much change is expected on the
> >>> > > maintenance
> >>> > > >> > > branches,
> >>> > > >> > > but if you want every change in the maintenance branch to go
> >>> into
> >>> > > the
> >>> > > >> > > main-line branch then there is little difference from a
> >>> conflict
> >>> > > point
> >>> > > >> of
> >>> > > >> > > view
> >>> > > >> > > between a series of cherry-picks and a merge.
> >>> > > >> > >
> >>> > > >> > > Either way, it is just another approach to consider. There’s
> >>> more
> >>> > > than
> >>> > > >> > one
> >>> > > >> > > way to do it, and I suspect there isn’t any solution that
> >>> makes it
> >>> > > >> > trivial.
> >>> > > >> > >
> >>> > > >> > > Cheers,
> >>> > > >> > > Richard
> >>> > > >> > >
> >>> > > >> > >
> >>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <
> aldrinpiri@gmail.com
> >>> >
> >>> > > wrote:
> >>> > > >> > > >
> >>> > > >> > > > On board with Tony's points. I think the realities of
> >>> merging
> >>> > in
> >>> > > >> > > practice
> >>> > > >> > > > when that "breaking point" of sorts occurs will make the
> >>> > > complexity
> >>> > > >> and
> >>> > > >> > > > overhead quite difficult and maybe even more error prone
> >>> than
> >>> > the
> >>> > > >> > cherry
> >>> > > >> > > > picking approach with some additional guidelines. When
> the
> >>> > > codebase
> >>> > > >> > > > drastically changes, the merge conflicts could be quite
> >>> severe
> >>> > and
> >>> > > >> > > without
> >>> > > >> > > > a good knowledge of each part of the codebase involved
> >>> during
> >>> > that
> >>> > > >> > > process,
> >>> > > >> > > > a committer may introduce regressions.
> >>> > > >> > > >
> >>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <
> >>> trkurc@gmail.com>
> >>> > > wrote:
> >>> > > >> > > >
> >>> > > >> > > >> the reason I like applying patches to both lines is that
> >>> once
> >>> > > code
> >>> > > >> > > begins
> >>> > > >> > > >> to diverge, cleanly merging into one codebase can be
> >>> > impossible.
> >>> > > >> > having
> >>> > > >> > > >> good practices for managing patches and where they apply
> is
> >>> > > >> paramount
> >>> > > >> > > for
> >>> > > >> > > >> success.
> >>> > > >> > > >>
> >>> > > >> > > >> I expect that divergence to happen with 1.x. I wanted to
> >>> get
> >>> > in a
> >>> > > >> > battle
> >>> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
> >>> patches
> >>> > > >> COULD
> >>> > > >> > be
> >>> > > >> > > >> applied to both in the manner you described.
> >>> > > >> > > >>
> >>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
> >>> tickets
> >>> > > >> marked
> >>> > > >> > > for
> >>> > > >> > > >> 0.5.1 had the right patches in the support branch, and
> some
> >>> > > didn't,
> >>> > > >> > so I
> >>> > > >> > > >> think "lesson learned". I do like in the apache
> >>> infrastructure
> >>> > > that
> >>> > > >> if
> >>> > > >> > > >> commits have the appropriate ticket in their commit
> >>> message,
> >>> > the
> >>> > > >> jira
> >>> > > >> > > will
> >>> > > >> > > >> have the list of commits and branches those commits were
> >>> > applies
> >>> > > to.
> >>> > > >> > > >> However, I think we may need to revisit commit message
> >>> > > "hygiene" if
> >>> > > >> > we
> >>> > > >> > > >> relied on this instead of more manual review.
> >>> > > >> > > >>
> >>> > > >> > > >>
> >>> > > >> > > >>
> >>> > > >> > > >>
> >>> > > >> > > >>
> >>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> >>> > > >> r.p.miskin@gmail.com
> >>> > > >> > >
> >>> > > >> > > >> wrote:
> >>> > > >> > > >>
> >>> > > >> > > >>> Hi,
> >>> > > >> > > >>>
> >>> > > >> > > >>> On a couple of work projects we found that the approach
> of
> >>> > > >> > > cherry-picking
> >>> > > >> > > >>> commits can lead to an unnecessarily complicated history
> >>> where
> >>> > > the
> >>> > > >> > same
> >>> > > >> > > >>> piece of work appears as multiple separate commits on
> >>> > different
> >>> > > >> > > branches.
> >>> > > >> > > >>> This can then make it hard to be confident that a bug
> fix
> >>> has
> >>> > > been
> >>> > > >> > > >> applied
> >>> > > >> > > >>> to all relevant branches. We found that it works better
> >>> to aim
> >>> > > to
> >>> > > >> > > commit
> >>> > > >> > > >>> changes to the lowest applicable branch, and then
> >>> regularly
> >>> > > merge
> >>> > > >> > those
> >>> > > >> > > >>> branches to master. This approach is based on the
> git-flow
> >>> > > model (
> >>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/
> <
> >>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/
> >>> >).
> >>> > > >> > > >>>
> >>> > > >> > > >>> Looking at the repo there are already a few commits that
> >>> are
> >>> > > >> > duplicated
> >>> > > >> > > >> on
> >>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d only
> >>> occur
> >>> > on
> >>> > > >> > 0.5.1,
> >>> > > >> > > >> and
> >>> > > >> > > >>> then that branch would get merged to master.
> >>> > > >> > > >>>
> >>> > > >> > > >>> Having the merge commits from the support branch to
> master
> >>> > > makes it
> >>> > > >> > > >>> explicit in the git history that all bug fixes (and
> >>> associated
> >>> > > >> tests)
> >>> > > >> > > >> have
> >>> > > >> > > >>> been pulled through to master.
> >>> > > >> > > >>>
> >>> > > >> > > >>> Cheers,
> >>> > > >> > > >>> Richard
> >>> > > >> > > >>>
> >>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jvwing@gmail.com
> >
> >>> > wrote:
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and
> >>> see if
> >>> > > you
> >>> > > >> > > agree:
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> 1.) Commits merged to master today are destined for the
> >>> next
> >>> > > minor
> >>> > > >> > > >>> release,
> >>> > > >> > > >>>> currently 0.6.0, by default?
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> By default, commits to master will be released in the
> >>> next
> >>> > > major
> >>> > > >> or
> >>> > > >> > > >> minor
> >>> > > >> > > >>>> release. No commits are included in incremental/patch
> >>> > > releases by
> >>> > > >> > > >>> default.
> >>> > > >> > > >>>>
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> support/0.5.x will be maintained until the first of the
> >>> > > following
> >>> > > >> > > >> events:
> >>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major
> >>> release
> >>> > > line)
> >>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
> >>> release
> >>> > > >> lines
> >>> > > >> > up
> >>> > > >> > > >> to
> >>> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in
> >>> that
> >>> > > >> line")
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> But additional support might be available by special
> >>> request.
> >>> > > >> > > >>>>
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined for a
> >>> > future
> >>> > > >> major
> >>> > > >> > > >>>> release stored? Is it visible anywhere?
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> I suppose Jira tickets targeting the next major release
> >>> > > >> > > >>> could/should/would
> >>> > > >> > > >>>> (do?) push branches. That seems weak in the face of a
> >>> > probable
> >>> > > >> > > >> stampede
> >>> > > >> > > >>>> towards the fire exit of a major release, but it's a
> >>> start.
> >>> > > I'm
> >>> > > >> not
> >>> > > >> > > >>> aware
> >>> > > >> > > >>>> of any great solutions here, certainly not for an
> >>> open-source
> >>> > > >> > project.
> >>> > > >> > > >>>>
> >>> > > >> > > >>>>
> >>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
> >>> > joe.witt@gmail.com>
> >>> > > >> > wrote:
> >>> > > >> > > >>>>
> >>> > > >> > > >>>>> James,
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> These are great questions to frame and test the model.
> >>> So
> >>> > > let's
> >>> > > >> > > >>>>> attempt to address them agains the model.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> Here is the language for that model at this time:
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> - 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'
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> So with those above let's review 1 through 5 in turn.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> 1.) Commits merged to master today are destined for
> the
> >>> next
> >>> > > >> minor
> >>> > > >> > > >>>>> release, currently 0.6.0, by default?
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> Master is for whatever is the most leading edge
> release
> >>> line
> >>> > > >> > working
> >>> > > >> > > >>>>> toward the next release. At the time that a minor
> >>> release
> >>> > > occurs
> >>> > > >> > > >>>>> against that release line then it branches off into a
> >>> > > >> support/x.y.*
> >>> > > >> > > >>>>> branch for any further efforts against it.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> 2.) Is master always open for merging new code, or are
> >>> there
> >>> > > >> > > >>> restrictions
> >>> > > >> > > >>>>> before or after releases?
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> I believe master would be always open for new code.
> >>> From
> >>> > some
> >>> > > >> > point
> >>> > > >> > > >>>>> at which a release is considered feature complete then
> >>> > further
> >>> > > >> > > feature
> >>> > > >> > > >>>>> enhancements need to go on master as part of the next
> >>> > release
> >>> > > >> > effort.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> The most recent minor release line of a major line
> will
> >>> be
> >>> > > >> > supported
> >>> > > >> > > >>>>> for up to one year from whenever it was released where
> >>> > > support is
> >>> > > >> > for
> >>> > > >> > > >>>>> bug fixes for security or data loss related items.
> >>> Releases
> >>> > > for
> >>> > > >> > > older
> >>> > > >> > > >>>>> minor lines should be considered on a case by case
> >>> basis and
> >>> > > if
> >>> > > >> > > >>>>> requested. Otherwise the basic premise is the train
> is
> >>> > moving
> >>> > > >> > > >>>>> forward.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined for
> a
> >>> > future
> >>> > > >> > major
> >>> > > >> > > >>>>> release stored? Is it visible anywhere?
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> It must be visible. It should be placed into a branch
> >>> until
> >>> > > such
> >>> > > >> > > >>>>> time that it is ready to become the new master. That
> >>> time
> >>> > > would
> >>> > > >> be
> >>> > > >> > > >>>>> when the next release will be for that line. When I
> >>> think
> >>> > > about
> >>> > > >> > this
> >>> > > >> > > >>>>> against the stated model we could probably tweak the
> >>> wording
> >>> > > to
> >>> > > >> > > better
> >>> > > >> > > >>>>> articulate that. I think it was what was meant with
> >>> 'when
> >>> > > master
> >>> > > >> > has
> >>> > > >> > > >>>>> no releases we will backport...' but that is unclear.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
> >>> > > eligible
> >>> > > >> to
> >>> > > >> > be
> >>> > > >> > > >>>>> backported only to the last minor release in the 0.x
> >>> line,
> >>> > or
> >>> > > to
> >>> > > >> > all
> >>> > > >> > > >>> minor
> >>> > > >> > > >>>>> releases in the 0.x line?
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> Only to the most recent minor release of any still
> >>> supported
> >>> > > >> major
> >>> > > >> > > >>>>> line. However, the catch of 'case by case'
> >>> determination
> >>> > for
> >>> > > >> older
> >>> > > >> > > >>>>> minor lines is still in play. Basically if someone
> >>> requests
> >>> > > it
> >>> > > >> and
> >>> > > >> > > >>>>> can get enough momentum for it then it should be no
> >>> problem
> >>> > to
> >>> > > >> > > produce
> >>> > > >> > > >>>>> such a release.
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> Thanks
> >>> > > >> > > >>>>> Joe
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
> >>> > jvwing@gmail.com
> >>> > > >
> >>> > > >> > > wrote:
> >>> > > >> > > >>>>>> I have some rhetorical questions for discussion of
> the
> >>> > > branching
> >>> > > >> > > >> model:
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> 1.) Commits merged to master today are destined for
> the
> >>> > next
> >>> > > >> minor
> >>> > > >> > > >>>>> release,
> >>> > > >> > > >>>>>> currently 0.6.0, by default?
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> 2.) Is master always open for merging new code, or
> are
> >>> > there
> >>> > > >> > > >>> restrictions
> >>> > > >> > > >>>>>> before or after releases?
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined
> for a
> >>> > > future
> >>> > > >> > major
> >>> > > >> > > >>>>>> release stored? Is it visible anywhere?
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0
> would
> >>> > > eligible
> >>> > > >> to
> >>> > > >> > > be
> >>> > > >> > > >>>>>> backported only to the last minor release in the 0.x
> >>> line,
> >>> > > or to
> >>> > > >> > all
> >>> > > >> > > >>>>> minor
> >>> > > >> > > >>>>>> releases in the 0.x line?
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> >>> > > joe.witt@gmail.com>
> >>> > > >> > > >> wrote:
> >>> > > >> > > >>>>>>
> >>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it
> >>> more
> >>> > > >> toward
> >>> > > >> > a
> >>> > > >> > > >>>>>>> proposal as we're at a point now where we need to
> >>> start
> >>> > > >> executing
> >>> > > >> > > >> some
> >>> > > >> > > >>>>>>> of these approaches. We're actually already seeing
> it
> >>> > take
> >>> > > >> form
> >>> > > >> > in
> >>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch
> (which
> >>> is
> >>> > for
> >>> > > >> > 0.6.0
> >>> > > >> > > >> at
> >>> > > >> > > >>>>>>> this point).
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>>> The proposal then for Git processes based on the
> other
> >>> > > thread
> >>> > > >> [1]
> >>> > > >> > > >>>>>>> where we outline a support model:
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>>> - 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
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>>> [1]
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>
> >>> > > >> > > >>
> >>> > > >> > >
> >>> > > >> >
> >>> > > >>
> >>> > >
> >>> >
> >>>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>>> Thanks
> >>> > > >> > > >>>>>>> Joe
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> >>> > > joe.witt@gmail.com>
> >>> > > >> > > >> wrote:
> >>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
> >>> discuss
> >>> > > >> > specific
> >>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
> >>> consensus
> >>> > > >> > > discussion
> >>> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
> >>> kicked
> >>> > > off a
> >>> > > >> > > >>>>>>>> discussion back at that level.
> >>> > > >> > > >>>>>>>>
> >>> > > >> > > >>>>>>>>
> >>> > > >> > > >>>>>>>>
> >>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> >>> > > trkurc@gmail.com>
> >>> > > >> > > >> wrote:
> >>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of
> the
> >>> > > plugins
> >>> > > >> > that
> >>> > > >> > > >> are
> >>> > > >> > > >>>>>>> used.
> >>> > > >> > > >>>>>>>>> I have worked on some other projects
> (unfortunately
> >>> not
> >>> > > open
> >>> > > >> > > >> source)
> >>> > > >> > > >>>>>>> that
> >>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever
> using
> >>> a
> >>> > > plugin.
> >>> > > >> > > Nice
> >>> > > >> > > >>>>> side
> >>> > > >> > > >>>>>>>>> effect is that I believe this got me better at
> using
> >>> > git,
> >>> > > and
> >>> > > >> > > >>>>> generally
> >>> > > >> > > >>>>>>> we
> >>> > > >> > > >>>>>>>>> all got better at managing merge pain.
> >>> > > >> > > >>>>>>>>>
> >>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're
> >>> operating
> >>> > the
> >>> > > way
> >>> > > >> > we
> >>> > > >> > > >> are
> >>> > > >> > > >>>>>>> now is
> >>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar
> for a
> >>> > > patch is
> >>> > > >> > > "can
> >>> > > >> > > >>> be
> >>> > > >> > > >>>>>>>>> merged into master", and we have our friend Travis
> >>> to
> >>> > make
> >>> > > >> this
> >>> > > >> > > >> even
> >>> > > >> > > >>>>>>> easier
> >>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things.
> If
> >>> a
> >>> > > bugfix
> >>> > > >> is
> >>> > > >> > > >>>>> "patch
> >>> > > >> > > >>>>>>>>> needs to be able to apply onto the current release
> >>> in
> >>> > > >> progress,
> >>> > > >> > > >>>>> master,
> >>> > > >> > > >>>>>>> and
> >>> > > >> > > >>>>>>>>> several other versions we're supporting, with
> >>> possibly
> >>> > > >> > > drastically
> >>> > > >> > > >>>>>>>>> different code", well then things get interesting.
> >>> > > >> > > >>>>>>>>>
> >>> > > >> > > >>>>>>>>>
> >>> > > >> > > >>>>>>>>>
> >>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson
> Margulies <
> >>> > > >> > > >>>>>>> bimargulies@gmail.com>
> >>> > > >> > > >>>>>>>>> wrote:
> >>> > > >> > > >>>>>>>>>
> >>> > > >> > > >>>>>>>>>> The issue tracker
> >>> > > >> > > >>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>
> >>> > > >> > > >>
> >>> > > >> > >
> >>> > > >> >
> >>> > > >>
> >>> > >
> >>> >
> >>>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
> >>> > > >> > > >>>>>>>>>>
> >>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson
> Margulies
> >>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> >>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It
> >>> worked
> >>> > > >> great,
> >>> > > >> > > >>>>> until
> >>> > > >> > > >>>>>>> it
> >>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible,
> inexplicable,
> >>> > merge
> >>> > > >> > > >> problems.
> >>> > > >> > > >>>>> No
> >>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
> >>> > > >> > > >>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
> >>> > > >> > > >>>>>>>>>>>
> >>> > > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin
> .
> >>> > > >> > > >>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> >>> > > >> > adam@adamtaft.com
> >>> > > >> > > >
> >>> > > >> > > >>>>>>> wrote:
> >>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using
> >>> it in
> >>> > > >> > > >> combination
> >>> > > >> > > >>>>>>> with
> >>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases
> are
> >>> > > tracking
> >>> > > >> > > >>>>> closely
> >>> > > >> > > >>>>>>> with
> >>> > > >> > > >>>>>>>>>> the
> >>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
> >>> doesn't
> >>> > > keep
> >>> > > >> > the
> >>> > > >> > > >> pom
> >>> > > >> > > >>>>>>>>>> version
> >>> > > >> > > >>>>>>>>>>>> updated with the git release names.
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
> >>> releases
> >>> > > and
> >>> > > >> > tags
> >>> > > >> > > >>>>>>>>>> synchronized
> >>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do,
> it
> >>> > needs
> >>> > > to
> >>> > > >> be
> >>> > > >> > > >>>>>>> approached
> >>> > > >> > > >>>>>>>>>>>> with tools that are available through maven
> >>> rather
> >>> > than
> >>> > > >> from
> >>> > > >> > > >> git.
> >>> > > >> > > >>>>>>> The
> >>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
> >>> directly
> >>> > > help
> >>> > > >> > > deal
> >>> > > >> > > >>>>> with
> >>> > > >> > > >>>>>>>>>> this
> >>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a
> >>> maven
> >>> > > tool.
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
> >>> > jgitflow
> >>> > > [1]
> >>> > > >> > > >>>>> plugin,
> >>> > > >> > > >>>>>>> which
> >>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow
> >>> model
> >>> > > for a
> >>> > > >> > > >> maven
> >>> > > >> > > >>>>>>>>>> project.
> >>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because
> >>> it
> >>> > > insists
> >>> > > >> > > that
> >>> > > >> > > >>>>> the
> >>> > > >> > > >>>>>>>>>> master
> >>> > > >> > > >>>>>>>>>>>> branch is strictly used for published release
> >>> tags
> >>> > (as
> >>> > > per
> >>> > > >> > the
> >>> > > >> > > >>>>>>> strict
> >>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
> >>> reference
> >>> > > to
> >>> > > >> how
> >>> > > >> > > >> some
> >>> > > >> > > >>>>>>>>>> plugins
> >>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven
> >>> synchronization
> >>> > > issue.
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> >>> > > >> > > >>>>> thadguidry@gmail.com
> >>> > > >> > > >>>>>>>>
> >>> > > >> > > >>>>>>>>>> wrote:
> >>> > > >> > > >>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow.
> >>> Your
> >>> > > >> Master
> >>> > > >> > > >>>>> become
> >>> > > >> > > >>>>>>>>>> primary
> >>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
> >>> branches
> >>> > > off of
> >>> > > >> > > >> it)..
> >>> > > >> > > >>>>>>> while
> >>> > > >> > > >>>>>>>>>> you
> >>> > > >> > > >>>>>>>>>>>>> continue to have release branches that can
> have
> >>> hot
> >>> > > fix
> >>> > > >> > > >> branches
> >>> > > >> > > >>>>>>> off of
> >>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release
> branch
> >>> ! -
> >>> > > bad
> >>> > > >> > > >>>>> practice !
> >>> > > >> > > >>>>>>> )
> >>> > > >> > > >>>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it
> >>> easy for
> >>> > > >> > everyone
> >>> > > >> > > >> to
> >>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
> >>> > > >> > understanding.
> >>> > > >> > > >> Its
> >>> > > >> > > >>>>>>> really
> >>> > > >> > > >>>>>>>>>>>>> that easy.
> >>> > > >> > > >>>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>>
> >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>> > > >> > > >>>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
> >>> git-flow
> >>> > ...
> >>> > > >> and
> >>> > > >> > > >> tools
> >>> > > >> > > >>>>>>> like
> >>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
> >>> > > Git-flow
> >>> > > >> > > either
> >>> > > >> > > >>>>>>> built
> >>> > > >> > > >>>>>>>>>> in or
> >>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on
> >>> the
> >>> > > command
> >>> > > >> > > >> line,
> >>> > > >> > > >>>>>>> then
> >>> > > >> > > >>>>>>>>>> that
> >>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the
> >>> above
> >>> > > link.
> >>> > > >> > > >>>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>>>> Thad
> >>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <
> https://www.google.com/+ThadGuidry
> >>> >
> >>> > > >> > > >>>>>>>>>>>>>
> >>> > > >> > > >>>>>>>>>>
> >>> > > >> > > >>>>>>>
> >>> > > >> > > >>>>>
> >>> > > >> > > >>>
> >>> > > >> > > >>>
> >>> > > >> > > >>
> >>> > > >> > >
> >>> > > >> > >
> >>> > > >> >
> >>> > > >>
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
All,
I have completed the branching discussed last week.
- master contains the current 1.x baseline - Future 1.x releases will start
from here
- 0.x contains the 0.x baseline - Future 0.x releases will start from here
Going forward all PRs will need to be merged the either or both branches as
appropriate to ensure it's included in subsequent releases. I will be
updating the quick start and contributor guide to describe the distinction
between the two branches.
Thanks!
Matt
On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <ma...@gmail.com>
wrote:
> The majority consensus is to have master point to our 1.x baseline going
> forward. Unless there are any strong objections I will set everything up on
> Monday (4/4) morning.
>
> - Create a 0.x branch for all future 0.x releases based on the current
> state of master.
> - Apply all 1.x commits from the temporary 1.x branch to master.
> - Delete the temporary 1.x branch.
> - Update the quickstart page and contribution guide to detail the
> distinction between the 0.x and master branches.
> - Send another email to @dev once this has been completed.
>
> Reminder: Going forward once this has been completed all commits will need
> to be made to both branches as appropriate.
>
> Thanks!
>
> Matt
>
> On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <ma...@gmail.com>
> wrote:
>
>> Matt,
>>
>> I agree that the PRs would need to be merged to both baselines at
>> contribution time. If the contribution applies cleanly the reviewer could
>> certainly handle the commit themselves. However, if additional code changes
>> are required because the baselines have diverged, the contributor would
>> probably need to submit another PR. This additional effort should only be
>> necessary until we're able to perform the first 1.x release.
>>
>> Aldrin,
>>
>> I definitely understand your thoughts regarding (1) and (2). This is why
>> I wanted to pose the options before just jumping into one approach vs the
>> other. I personally prefer the GitHub style PR process. I realize this is
>> more cumbersome but hopefully the number of conflicts should be small as
>> folks are already starting to focus their efforts on the framework for 1.x.
>>
>> Matt
>>
>> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com>
>> wrote:
>>
>>> I think I prefer option 2 considering, what may be the incorrect
>>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be easier.
>>> Based on outstanding PRs/Patches in conjunction with release cadence
>>> there
>>> will be more 0.x releases planned. Until we reached the point where the
>>> first 1.x release is in sight, I think (2) makes sense just from
>>> minimizing
>>> impedance where the majority of effort will occur (new/updated
>>> extensions)
>>> and then switching to (1) when we are scheduling 1.x as next (exclusive
>>> of
>>> any patch builds). This seems to work out when I try to reason about it,
>>> but admittedly, am coming at this heavily from my own anecdotal
>>> perspective
>>> given my flow of reviewing.
>>>
>>> Matt, excellent points to consider.
>>>
>>> Do not want to go too much on a tangent from the current conversation,
>>> but
>>> I think we need to harness automation as much as possible. Not sure
>>> Travis
>>> can do this or do so easily (short of two PRs) and this may arguably
>>> shift
>>> things in favor of patches and the model that the other ASF projects
>>> utilize with buildbot. Getting as much done asynchronously for us is
>>> obviously important but we also have to strive to avoid a contrib process
>>> that is too cumbersome as well.
>>>
>>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
>>> wrote:
>>>
>>> > I like option 1 as well.
>>> >
>>> > In the case where a fix is to be put into both branches, will the
>>> developer
>>> > be responsible for issuing 2 PRs / patches, one against each branch?
>>> This
>>> > would help in the case that the PR/patch against 0.x won't merge
>>> cleanly
>>> > into master; however the reviewer(s) would need to make sure there
>>> were no
>>> > breaking changes as a result of the manual merge to master. An
>>> alternative
>>> > is that the reviewer(s) do the forward-port, which I don't think is a
>>> good
>>> > idea. However the reviewer would need to make sure the PR(s) are
>>> against
>>> > the correct branch. For example, all current PRs would need to be
>>> > "backported" to the new 0.x branch.
>>> >
>>> > Also, I would think the PRs/patches need to be merged at the same time
>>> (or
>>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but getting
>>> > forgotten/missed for 1.x).
>>> >
>>> > Thoughts? Thanks,
>>> > Matt
>>> >
>>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com> wrote:
>>> >
>>> > > I too prefer option 1
>>> > >
>>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu>
>>> wrote:
>>> > > > I agree with Tony on option 1. I think it makes sense for master
>>> to
>>> > be
>>> > > > the most "advanced" branch. New features will then always be
>>> applied
>>> > to
>>> > > > master, and optionally to other branches for older version support
>>> as
>>> > > > applicable / desired.
>>> > > >
>>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com>
>>> wrote:
>>> > > >
>>> > > >> I like option 1
>>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com>
>>> > > wrote:
>>> > > >>
>>> > > >> > Hello,
>>> > > >> >
>>> > > >> > With NiFi 0.6.0 officially released and our support strategy
>>> defined
>>> > > [1],
>>> > > >> > I'd like to revisit and propose some options for supporting
>>> both a
>>> > 1.x
>>> > > >> > branch and 0.x branch concurrently. We need an official place
>>> where
>>> > > these
>>> > > >> > efforts can be worked, contributed to, and collaborated with the
>>> > > >> community.
>>> > > >> > I've already created a 1.x branch as a temporary place for this
>>> > > codebase
>>> > > >> to
>>> > > >> > live until we agree to an approach.
>>> > > >> >
>>> > > >> > Either option I'm proposing will require
>>> PRs/contributions/patches
>>> > to
>>> > > be
>>> > > >> > applied to both branches as applicable. This means that the
>>> > > contributor
>>> > > >> or
>>> > > >> > the reviewer will need to be able to apply the commits in both
>>> > places
>>> > > if
>>> > > >> > it's necessary. For instance, framework code has already started
>>> > > >> diverging
>>> > > >> > from the current master so any framework change may not need to
>>> be
>>> > > >> applied
>>> > > >> > to both if the changeset is not applicable to the 1.x baseline.
>>> > > >> >
>>> > > >> > The only question at the moment is what master will refer to.
>>> > > >> >
>>> > > >> > 1) Create a branch for 0.x and allow master to become the 1.x
>>> > baseline
>>> > > >> > going forward. Future 0.x releases will be performed from the
>>> 0.x
>>> > > branch.
>>> > > >> > 2) Continuing working on the 1.x branch as is. Allow master to
>>> > > continue
>>> > > >> to
>>> > > >> > servicing 0.x releases. Once a 1.x release is made, create the
>>> 0.x
>>> > > branch
>>> > > >> > and then allow master to service 1.x releases.
>>> > > >> >
>>> > > >> > In short, when do we want master to point to the 1.x baseline?
>>> When
>>> > > >> should
>>> > > >> > we create a branch where 0.x releases will be made from.
>>> Regardless,
>>> > > >> > contributions will need to be performed to both places as
>>> > applicable.
>>> > > >> >
>>> > > >> > Thanks.
>>> > > >> >
>>> > > >> > Matt
>>> > > >> >
>>> > > >> > [1]
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> > >
>>> >
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>>> > > >> >
>>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
>>> > > r.p.miskin@gmail.com>
>>> > > >> > wrote:
>>> > > >> >
>>> > > >> > > I guess it will depend how much change is expected on the
>>> > > maintenance
>>> > > >> > > branches,
>>> > > >> > > but if you want every change in the maintenance branch to go
>>> into
>>> > > the
>>> > > >> > > main-line branch then there is little difference from a
>>> conflict
>>> > > point
>>> > > >> of
>>> > > >> > > view
>>> > > >> > > between a series of cherry-picks and a merge.
>>> > > >> > >
>>> > > >> > > Either way, it is just another approach to consider. There’s
>>> more
>>> > > than
>>> > > >> > one
>>> > > >> > > way to do it, and I suspect there isn’t any solution that
>>> makes it
>>> > > >> > trivial.
>>> > > >> > >
>>> > > >> > > Cheers,
>>> > > >> > > Richard
>>> > > >> > >
>>> > > >> > >
>>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <aldrinpiri@gmail.com
>>> >
>>> > > wrote:
>>> > > >> > > >
>>> > > >> > > > On board with Tony's points. I think the realities of
>>> merging
>>> > in
>>> > > >> > > practice
>>> > > >> > > > when that "breaking point" of sorts occurs will make the
>>> > > complexity
>>> > > >> and
>>> > > >> > > > overhead quite difficult and maybe even more error prone
>>> than
>>> > the
>>> > > >> > cherry
>>> > > >> > > > picking approach with some additional guidelines. When the
>>> > > codebase
>>> > > >> > > > drastically changes, the merge conflicts could be quite
>>> severe
>>> > and
>>> > > >> > > without
>>> > > >> > > > a good knowledge of each part of the codebase involved
>>> during
>>> > that
>>> > > >> > > process,
>>> > > >> > > > a committer may introduce regressions.
>>> > > >> > > >
>>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <
>>> trkurc@gmail.com>
>>> > > wrote:
>>> > > >> > > >
>>> > > >> > > >> the reason I like applying patches to both lines is that
>>> once
>>> > > code
>>> > > >> > > begins
>>> > > >> > > >> to diverge, cleanly merging into one codebase can be
>>> > impossible.
>>> > > >> > having
>>> > > >> > > >> good practices for managing patches and where they apply is
>>> > > >> paramount
>>> > > >> > > for
>>> > > >> > > >> success.
>>> > > >> > > >>
>>> > > >> > > >> I expect that divergence to happen with 1.x. I wanted to
>>> get
>>> > in a
>>> > > >> > battle
>>> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
>>> patches
>>> > > >> COULD
>>> > > >> > be
>>> > > >> > > >> applied to both in the manner you described.
>>> > > >> > > >>
>>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
>>> tickets
>>> > > >> marked
>>> > > >> > > for
>>> > > >> > > >> 0.5.1 had the right patches in the support branch, and some
>>> > > didn't,
>>> > > >> > so I
>>> > > >> > > >> think "lesson learned". I do like in the apache
>>> infrastructure
>>> > > that
>>> > > >> if
>>> > > >> > > >> commits have the appropriate ticket in their commit
>>> message,
>>> > the
>>> > > >> jira
>>> > > >> > > will
>>> > > >> > > >> have the list of commits and branches those commits were
>>> > applies
>>> > > to.
>>> > > >> > > >> However, I think we may need to revisit commit message
>>> > > "hygiene" if
>>> > > >> > we
>>> > > >> > > >> relied on this instead of more manual review.
>>> > > >> > > >>
>>> > > >> > > >>
>>> > > >> > > >>
>>> > > >> > > >>
>>> > > >> > > >>
>>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
>>> > > >> r.p.miskin@gmail.com
>>> > > >> > >
>>> > > >> > > >> wrote:
>>> > > >> > > >>
>>> > > >> > > >>> Hi,
>>> > > >> > > >>>
>>> > > >> > > >>> On a couple of work projects we found that the approach of
>>> > > >> > > cherry-picking
>>> > > >> > > >>> commits can lead to an unnecessarily complicated history
>>> where
>>> > > the
>>> > > >> > same
>>> > > >> > > >>> piece of work appears as multiple separate commits on
>>> > different
>>> > > >> > > branches.
>>> > > >> > > >>> This can then make it hard to be confident that a bug fix
>>> has
>>> > > been
>>> > > >> > > >> applied
>>> > > >> > > >>> to all relevant branches. We found that it works better
>>> to aim
>>> > > to
>>> > > >> > > commit
>>> > > >> > > >>> changes to the lowest applicable branch, and then
>>> regularly
>>> > > merge
>>> > > >> > those
>>> > > >> > > >>> branches to master. This approach is based on the git-flow
>>> > > model (
>>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
>>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/
>>> >).
>>> > > >> > > >>>
>>> > > >> > > >>> Looking at the repo there are already a few commits that
>>> are
>>> > > >> > duplicated
>>> > > >> > > >> on
>>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d only
>>> occur
>>> > on
>>> > > >> > 0.5.1,
>>> > > >> > > >> and
>>> > > >> > > >>> then that branch would get merged to master.
>>> > > >> > > >>>
>>> > > >> > > >>> Having the merge commits from the support branch to master
>>> > > makes it
>>> > > >> > > >>> explicit in the git history that all bug fixes (and
>>> associated
>>> > > >> tests)
>>> > > >> > > >> have
>>> > > >> > > >>> been pulled through to master.
>>> > > >> > > >>>
>>> > > >> > > >>> Cheers,
>>> > > >> > > >>> Richard
>>> > > >> > > >>>
>>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com>
>>> > wrote:
>>> > > >> > > >>>>
>>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and
>>> see if
>>> > > you
>>> > > >> > > agree:
>>> > > >> > > >>>>
>>> > > >> > > >>>> 1.) Commits merged to master today are destined for the
>>> next
>>> > > minor
>>> > > >> > > >>> release,
>>> > > >> > > >>>> currently 0.6.0, by default?
>>> > > >> > > >>>>
>>> > > >> > > >>>> By default, commits to master will be released in the
>>> next
>>> > > major
>>> > > >> or
>>> > > >> > > >> minor
>>> > > >> > > >>>> release. No commits are included in incremental/patch
>>> > > releases by
>>> > > >> > > >>> default.
>>> > > >> > > >>>>
>>> > > >> > > >>>>
>>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
>>> > > >> > > >>>>
>>> > > >> > > >>>> support/0.5.x will be maintained until the first of the
>>> > > following
>>> > > >> > > >> events:
>>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major
>>> release
>>> > > line)
>>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
>>> release
>>> > > >> lines
>>> > > >> > up
>>> > > >> > > >> to
>>> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in
>>> that
>>> > > >> line")
>>> > > >> > > >>>>
>>> > > >> > > >>>> But additional support might be available by special
>>> request.
>>> > > >> > > >>>>
>>> > > >> > > >>>>
>>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined for a
>>> > future
>>> > > >> major
>>> > > >> > > >>>> release stored? Is it visible anywhere?
>>> > > >> > > >>>>
>>> > > >> > > >>>> I suppose Jira tickets targeting the next major release
>>> > > >> > > >>> could/should/would
>>> > > >> > > >>>> (do?) push branches. That seems weak in the face of a
>>> > probable
>>> > > >> > > >> stampede
>>> > > >> > > >>>> towards the fire exit of a major release, but it's a
>>> start.
>>> > > I'm
>>> > > >> not
>>> > > >> > > >>> aware
>>> > > >> > > >>>> of any great solutions here, certainly not for an
>>> open-source
>>> > > >> > project.
>>> > > >> > > >>>>
>>> > > >> > > >>>>
>>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
>>> > joe.witt@gmail.com>
>>> > > >> > wrote:
>>> > > >> > > >>>>
>>> > > >> > > >>>>> James,
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> These are great questions to frame and test the model.
>>> So
>>> > > let's
>>> > > >> > > >>>>> attempt to address them agains the model.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> Here is the language for that model at this time:
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> - 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'
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> So with those above let's review 1 through 5 in turn.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> 1.) Commits merged to master today are destined for the
>>> next
>>> > > >> minor
>>> > > >> > > >>>>> release, currently 0.6.0, by default?
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> Master is for whatever is the most leading edge release
>>> line
>>> > > >> > working
>>> > > >> > > >>>>> toward the next release. At the time that a minor
>>> release
>>> > > occurs
>>> > > >> > > >>>>> against that release line then it branches off into a
>>> > > >> support/x.y.*
>>> > > >> > > >>>>> branch for any further efforts against it.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> 2.) Is master always open for merging new code, or are
>>> there
>>> > > >> > > >>> restrictions
>>> > > >> > > >>>>> before or after releases?
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> I believe master would be always open for new code.
>>> From
>>> > some
>>> > > >> > point
>>> > > >> > > >>>>> at which a release is considered feature complete then
>>> > further
>>> > > >> > > feature
>>> > > >> > > >>>>> enhancements need to go on master as part of the next
>>> > release
>>> > > >> > effort.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> The most recent minor release line of a major line will
>>> be
>>> > > >> > supported
>>> > > >> > > >>>>> for up to one year from whenever it was released where
>>> > > support is
>>> > > >> > for
>>> > > >> > > >>>>> bug fixes for security or data loss related items.
>>> Releases
>>> > > for
>>> > > >> > > older
>>> > > >> > > >>>>> minor lines should be considered on a case by case
>>> basis and
>>> > > if
>>> > > >> > > >>>>> requested. Otherwise the basic premise is the train is
>>> > moving
>>> > > >> > > >>>>> forward.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined for a
>>> > future
>>> > > >> > major
>>> > > >> > > >>>>> release stored? Is it visible anywhere?
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> It must be visible. It should be placed into a branch
>>> until
>>> > > such
>>> > > >> > > >>>>> time that it is ready to become the new master. That
>>> time
>>> > > would
>>> > > >> be
>>> > > >> > > >>>>> when the next release will be for that line. When I
>>> think
>>> > > about
>>> > > >> > this
>>> > > >> > > >>>>> against the stated model we could probably tweak the
>>> wording
>>> > > to
>>> > > >> > > better
>>> > > >> > > >>>>> articulate that. I think it was what was meant with
>>> 'when
>>> > > master
>>> > > >> > has
>>> > > >> > > >>>>> no releases we will backport...' but that is unclear.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
>>> > > eligible
>>> > > >> to
>>> > > >> > be
>>> > > >> > > >>>>> backported only to the last minor release in the 0.x
>>> line,
>>> > or
>>> > > to
>>> > > >> > all
>>> > > >> > > >>> minor
>>> > > >> > > >>>>> releases in the 0.x line?
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> Only to the most recent minor release of any still
>>> supported
>>> > > >> major
>>> > > >> > > >>>>> line. However, the catch of 'case by case'
>>> determination
>>> > for
>>> > > >> older
>>> > > >> > > >>>>> minor lines is still in play. Basically if someone
>>> requests
>>> > > it
>>> > > >> and
>>> > > >> > > >>>>> can get enough momentum for it then it should be no
>>> problem
>>> > to
>>> > > >> > > produce
>>> > > >> > > >>>>> such a release.
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> Thanks
>>> > > >> > > >>>>> Joe
>>> > > >> > > >>>>>
>>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
>>> > jvwing@gmail.com
>>> > > >
>>> > > >> > > wrote:
>>> > > >> > > >>>>>> I have some rhetorical questions for discussion of the
>>> > > branching
>>> > > >> > > >> model:
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> 1.) Commits merged to master today are destined for the
>>> > next
>>> > > >> minor
>>> > > >> > > >>>>> release,
>>> > > >> > > >>>>>> currently 0.6.0, by default?
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> 2.) Is master always open for merging new code, or are
>>> > there
>>> > > >> > > >>> restrictions
>>> > > >> > > >>>>>> before or after releases?
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a
>>> > > future
>>> > > >> > major
>>> > > >> > > >>>>>> release stored? Is it visible anywhere?
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would
>>> > > eligible
>>> > > >> to
>>> > > >> > > be
>>> > > >> > > >>>>>> backported only to the last minor release in the 0.x
>>> line,
>>> > > or to
>>> > > >> > all
>>> > > >> > > >>>>> minor
>>> > > >> > > >>>>>> releases in the 0.x line?
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
>>> > > joe.witt@gmail.com>
>>> > > >> > > >> wrote:
>>> > > >> > > >>>>>>
>>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it
>>> more
>>> > > >> toward
>>> > > >> > a
>>> > > >> > > >>>>>>> proposal as we're at a point now where we need to
>>> start
>>> > > >> executing
>>> > > >> > > >> some
>>> > > >> > > >>>>>>> of these approaches. We're actually already seeing it
>>> > take
>>> > > >> form
>>> > > >> > in
>>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch (which
>>> is
>>> > for
>>> > > >> > 0.6.0
>>> > > >> > > >> at
>>> > > >> > > >>>>>>> this point).
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>>> The proposal then for Git processes based on the other
>>> > > thread
>>> > > >> [1]
>>> > > >> > > >>>>>>> where we outline a support model:
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>>> - 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
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>>> [1]
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>
>>> > > >> > > >>>
>>> > > >> > > >>
>>> > > >> > >
>>> > > >> >
>>> > > >>
>>> > >
>>> >
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>>> Thanks
>>> > > >> > > >>>>>>> Joe
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
>>> > > joe.witt@gmail.com>
>>> > > >> > > >> wrote:
>>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
>>> discuss
>>> > > >> > specific
>>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
>>> consensus
>>> > > >> > > discussion
>>> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
>>> kicked
>>> > > off a
>>> > > >> > > >>>>>>>> discussion back at that level.
>>> > > >> > > >>>>>>>>
>>> > > >> > > >>>>>>>>
>>> > > >> > > >>>>>>>>
>>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
>>> > > trkurc@gmail.com>
>>> > > >> > > >> wrote:
>>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the
>>> > > plugins
>>> > > >> > that
>>> > > >> > > >> are
>>> > > >> > > >>>>>>> used.
>>> > > >> > > >>>>>>>>> I have worked on some other projects (unfortunately
>>> not
>>> > > open
>>> > > >> > > >> source)
>>> > > >> > > >>>>>>> that
>>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using
>>> a
>>> > > plugin.
>>> > > >> > > Nice
>>> > > >> > > >>>>> side
>>> > > >> > > >>>>>>>>> effect is that I believe this got me better at using
>>> > git,
>>> > > and
>>> > > >> > > >>>>> generally
>>> > > >> > > >>>>>>> we
>>> > > >> > > >>>>>>>>> all got better at managing merge pain.
>>> > > >> > > >>>>>>>>>
>>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're
>>> operating
>>> > the
>>> > > way
>>> > > >> > we
>>> > > >> > > >> are
>>> > > >> > > >>>>>>> now is
>>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a
>>> > > patch is
>>> > > >> > > "can
>>> > > >> > > >>> be
>>> > > >> > > >>>>>>>>> merged into master", and we have our friend Travis
>>> to
>>> > make
>>> > > >> this
>>> > > >> > > >> even
>>> > > >> > > >>>>>>> easier
>>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If
>>> a
>>> > > bugfix
>>> > > >> is
>>> > > >> > > >>>>> "patch
>>> > > >> > > >>>>>>>>> needs to be able to apply onto the current release
>>> in
>>> > > >> progress,
>>> > > >> > > >>>>> master,
>>> > > >> > > >>>>>>> and
>>> > > >> > > >>>>>>>>> several other versions we're supporting, with
>>> possibly
>>> > > >> > > drastically
>>> > > >> > > >>>>>>>>> different code", well then things get interesting.
>>> > > >> > > >>>>>>>>>
>>> > > >> > > >>>>>>>>>
>>> > > >> > > >>>>>>>>>
>>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>>> > > >> > > >>>>>>> bimargulies@gmail.com>
>>> > > >> > > >>>>>>>>> wrote:
>>> > > >> > > >>>>>>>>>
>>> > > >> > > >>>>>>>>>> The issue tracker
>>> > > >> > > >>>>>>>>>>
>>> > > >> > > >>>>>>>>>>
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>
>>> > > >> > > >>>
>>> > > >> > > >>
>>> > > >> > >
>>> > > >> >
>>> > > >>
>>> > >
>>> >
>>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
>>> > > >> > > >>>>>>>>>>
>>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
>>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It
>>> worked
>>> > > >> great,
>>> > > >> > > >>>>> until
>>> > > >> > > >>>>>>> it
>>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable,
>>> > merge
>>> > > >> > > >> problems.
>>> > > >> > > >>>>> No
>>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
>>> > > >> > > >>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
>>> > > >> > > >>>>>>>>>>>
>>> > > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>>> > > >> > > >>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
>>> > > >> > adam@adamtaft.com
>>> > > >> > > >
>>> > > >> > > >>>>>>> wrote:
>>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using
>>> it in
>>> > > >> > > >> combination
>>> > > >> > > >>>>>>> with
>>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are
>>> > > tracking
>>> > > >> > > >>>>> closely
>>> > > >> > > >>>>>>> with
>>> > > >> > > >>>>>>>>>> the
>>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
>>> doesn't
>>> > > keep
>>> > > >> > the
>>> > > >> > > >> pom
>>> > > >> > > >>>>>>>>>> version
>>> > > >> > > >>>>>>>>>>>> updated with the git release names.
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
>>> releases
>>> > > and
>>> > > >> > tags
>>> > > >> > > >>>>>>>>>> synchronized
>>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it
>>> > needs
>>> > > to
>>> > > >> be
>>> > > >> > > >>>>>>> approached
>>> > > >> > > >>>>>>>>>>>> with tools that are available through maven
>>> rather
>>> > than
>>> > > >> from
>>> > > >> > > >> git.
>>> > > >> > > >>>>>>> The
>>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
>>> directly
>>> > > help
>>> > > >> > > deal
>>> > > >> > > >>>>> with
>>> > > >> > > >>>>>>>>>> this
>>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a
>>> maven
>>> > > tool.
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
>>> > jgitflow
>>> > > [1]
>>> > > >> > > >>>>> plugin,
>>> > > >> > > >>>>>>> which
>>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow
>>> model
>>> > > for a
>>> > > >> > > >> maven
>>> > > >> > > >>>>>>>>>> project.
>>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because
>>> it
>>> > > insists
>>> > > >> > > that
>>> > > >> > > >>>>> the
>>> > > >> > > >>>>>>>>>> master
>>> > > >> > > >>>>>>>>>>>> branch is strictly used for published release
>>> tags
>>> > (as
>>> > > per
>>> > > >> > the
>>> > > >> > > >>>>>>> strict
>>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
>>> reference
>>> > > to
>>> > > >> how
>>> > > >> > > >> some
>>> > > >> > > >>>>>>>>>> plugins
>>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven
>>> synchronization
>>> > > issue.
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
>>> > > >> > > >>>>> thadguidry@gmail.com
>>> > > >> > > >>>>>>>>
>>> > > >> > > >>>>>>>>>> wrote:
>>> > > >> > > >>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow.
>>> Your
>>> > > >> Master
>>> > > >> > > >>>>> become
>>> > > >> > > >>>>>>>>>> primary
>>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
>>> branches
>>> > > off of
>>> > > >> > > >> it)..
>>> > > >> > > >>>>>>> while
>>> > > >> > > >>>>>>>>>> you
>>> > > >> > > >>>>>>>>>>>>> continue to have release branches that can have
>>> hot
>>> > > fix
>>> > > >> > > >> branches
>>> > > >> > > >>>>>>> off of
>>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch
>>> ! -
>>> > > bad
>>> > > >> > > >>>>> practice !
>>> > > >> > > >>>>>>> )
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it
>>> easy for
>>> > > >> > everyone
>>> > > >> > > >> to
>>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
>>> > > >> > understanding.
>>> > > >> > > >> Its
>>> > > >> > > >>>>>>> really
>>> > > >> > > >>>>>>>>>>>>> that easy.
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>>
>>> http://danielkummer.github.io/git-flow-cheatsheet/
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
>>> git-flow
>>> > ...
>>> > > >> and
>>> > > >> > > >> tools
>>> > > >> > > >>>>>>> like
>>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
>>> > > Git-flow
>>> > > >> > > either
>>> > > >> > > >>>>>>> built
>>> > > >> > > >>>>>>>>>> in or
>>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on
>>> the
>>> > > command
>>> > > >> > > >> line,
>>> > > >> > > >>>>>>> then
>>> > > >> > > >>>>>>>>>> that
>>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the
>>> above
>>> > > link.
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>>>> Thad
>>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry
>>> >
>>> > > >> > > >>>>>>>>>>>>>
>>> > > >> > > >>>>>>>>>>
>>> > > >> > > >>>>>>>
>>> > > >> > > >>>>>
>>> > > >> > > >>>
>>> > > >> > > >>>
>>> > > >> > > >>
>>> > > >> > >
>>> > > >> > >
>>> > > >> >
>>> > > >>
>>> > >
>>> >
>>>
>>
>>
>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
The majority consensus is to have master point to our 1.x baseline going
forward. Unless there are any strong objections I will set everything up on
Monday (4/4) morning.
- Create a 0.x branch for all future 0.x releases based on the current
state of master.
- Apply all 1.x commits from the temporary 1.x branch to master.
- Delete the temporary 1.x branch.
- Update the quickstart page and contribution guide to detail the
distinction between the 0.x and master branches.
- Send another email to @dev once this has been completed.
Reminder: Going forward once this has been completed all commits will need
to be made to both branches as appropriate.
Thanks!
Matt
On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman <ma...@gmail.com>
wrote:
> Matt,
>
> I agree that the PRs would need to be merged to both baselines at
> contribution time. If the contribution applies cleanly the reviewer could
> certainly handle the commit themselves. However, if additional code changes
> are required because the baselines have diverged, the contributor would
> probably need to submit another PR. This additional effort should only be
> necessary until we're able to perform the first 1.x release.
>
> Aldrin,
>
> I definitely understand your thoughts regarding (1) and (2). This is why I
> wanted to pose the options before just jumping into one approach vs the
> other. I personally prefer the GitHub style PR process. I realize this is
> more cumbersome but hopefully the number of conflicts should be small as
> folks are already starting to focus their efforts on the framework for 1.x.
>
> Matt
>
> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com>
> wrote:
>
>> I think I prefer option 2 considering, what may be the incorrect
>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be easier.
>> Based on outstanding PRs/Patches in conjunction with release cadence there
>> will be more 0.x releases planned. Until we reached the point where the
>> first 1.x release is in sight, I think (2) makes sense just from
>> minimizing
>> impedance where the majority of effort will occur (new/updated extensions)
>> and then switching to (1) when we are scheduling 1.x as next (exclusive of
>> any patch builds). This seems to work out when I try to reason about it,
>> but admittedly, am coming at this heavily from my own anecdotal
>> perspective
>> given my flow of reviewing.
>>
>> Matt, excellent points to consider.
>>
>> Do not want to go too much on a tangent from the current conversation, but
>> I think we need to harness automation as much as possible. Not sure
>> Travis
>> can do this or do so easily (short of two PRs) and this may arguably shift
>> things in favor of patches and the model that the other ASF projects
>> utilize with buildbot. Getting as much done asynchronously for us is
>> obviously important but we also have to strive to avoid a contrib process
>> that is too cumbersome as well.
>>
>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
>> wrote:
>>
>> > I like option 1 as well.
>> >
>> > In the case where a fix is to be put into both branches, will the
>> developer
>> > be responsible for issuing 2 PRs / patches, one against each branch?
>> This
>> > would help in the case that the PR/patch against 0.x won't merge cleanly
>> > into master; however the reviewer(s) would need to make sure there were
>> no
>> > breaking changes as a result of the manual merge to master. An
>> alternative
>> > is that the reviewer(s) do the forward-port, which I don't think is a
>> good
>> > idea. However the reviewer would need to make sure the PR(s) are against
>> > the correct branch. For example, all current PRs would need to be
>> > "backported" to the new 0.x branch.
>> >
>> > Also, I would think the PRs/patches need to be merged at the same time
>> (or
>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but getting
>> > forgotten/missed for 1.x).
>> >
>> > Thoughts? Thanks,
>> > Matt
>> >
>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com> wrote:
>> >
>> > > I too prefer option 1
>> > >
>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu> wrote:
>> > > > I agree with Tony on option 1. I think it makes sense for master
>> to
>> > be
>> > > > the most "advanced" branch. New features will then always be
>> applied
>> > to
>> > > > master, and optionally to other branches for older version support
>> as
>> > > > applicable / desired.
>> > > >
>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com>
>> wrote:
>> > > >
>> > > >> I like option 1
>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com>
>> > > wrote:
>> > > >>
>> > > >> > Hello,
>> > > >> >
>> > > >> > With NiFi 0.6.0 officially released and our support strategy
>> defined
>> > > [1],
>> > > >> > I'd like to revisit and propose some options for supporting both
>> a
>> > 1.x
>> > > >> > branch and 0.x branch concurrently. We need an official place
>> where
>> > > these
>> > > >> > efforts can be worked, contributed to, and collaborated with the
>> > > >> community.
>> > > >> > I've already created a 1.x branch as a temporary place for this
>> > > codebase
>> > > >> to
>> > > >> > live until we agree to an approach.
>> > > >> >
>> > > >> > Either option I'm proposing will require
>> PRs/contributions/patches
>> > to
>> > > be
>> > > >> > applied to both branches as applicable. This means that the
>> > > contributor
>> > > >> or
>> > > >> > the reviewer will need to be able to apply the commits in both
>> > places
>> > > if
>> > > >> > it's necessary. For instance, framework code has already started
>> > > >> diverging
>> > > >> > from the current master so any framework change may not need to
>> be
>> > > >> applied
>> > > >> > to both if the changeset is not applicable to the 1.x baseline.
>> > > >> >
>> > > >> > The only question at the moment is what master will refer to.
>> > > >> >
>> > > >> > 1) Create a branch for 0.x and allow master to become the 1.x
>> > baseline
>> > > >> > going forward. Future 0.x releases will be performed from the 0.x
>> > > branch.
>> > > >> > 2) Continuing working on the 1.x branch as is. Allow master to
>> > > continue
>> > > >> to
>> > > >> > servicing 0.x releases. Once a 1.x release is made, create the
>> 0.x
>> > > branch
>> > > >> > and then allow master to service 1.x releases.
>> > > >> >
>> > > >> > In short, when do we want master to point to the 1.x baseline?
>> When
>> > > >> should
>> > > >> > we create a branch where 0.x releases will be made from.
>> Regardless,
>> > > >> > contributions will need to be performed to both places as
>> > applicable.
>> > > >> >
>> > > >> > Thanks.
>> > > >> >
>> > > >> > Matt
>> > > >> >
>> > > >> > [1]
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> > > >> >
>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
>> > > r.p.miskin@gmail.com>
>> > > >> > wrote:
>> > > >> >
>> > > >> > > I guess it will depend how much change is expected on the
>> > > maintenance
>> > > >> > > branches,
>> > > >> > > but if you want every change in the maintenance branch to go
>> into
>> > > the
>> > > >> > > main-line branch then there is little difference from a
>> conflict
>> > > point
>> > > >> of
>> > > >> > > view
>> > > >> > > between a series of cherry-picks and a merge.
>> > > >> > >
>> > > >> > > Either way, it is just another approach to consider. There’s
>> more
>> > > than
>> > > >> > one
>> > > >> > > way to do it, and I suspect there isn’t any solution that
>> makes it
>> > > >> > trivial.
>> > > >> > >
>> > > >> > > Cheers,
>> > > >> > > Richard
>> > > >> > >
>> > > >> > >
>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com>
>> > > wrote:
>> > > >> > > >
>> > > >> > > > On board with Tony's points. I think the realities of
>> merging
>> > in
>> > > >> > > practice
>> > > >> > > > when that "breaking point" of sorts occurs will make the
>> > > complexity
>> > > >> and
>> > > >> > > > overhead quite difficult and maybe even more error prone than
>> > the
>> > > >> > cherry
>> > > >> > > > picking approach with some additional guidelines. When the
>> > > codebase
>> > > >> > > > drastically changes, the merge conflicts could be quite
>> severe
>> > and
>> > > >> > > without
>> > > >> > > > a good knowledge of each part of the codebase involved during
>> > that
>> > > >> > > process,
>> > > >> > > > a committer may introduce regressions.
>> > > >> > > >
>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <trkurc@gmail.com
>> >
>> > > wrote:
>> > > >> > > >
>> > > >> > > >> the reason I like applying patches to both lines is that
>> once
>> > > code
>> > > >> > > begins
>> > > >> > > >> to diverge, cleanly merging into one codebase can be
>> > impossible.
>> > > >> > having
>> > > >> > > >> good practices for managing patches and where they apply is
>> > > >> paramount
>> > > >> > > for
>> > > >> > > >> success.
>> > > >> > > >>
>> > > >> > > >> I expect that divergence to happen with 1.x. I wanted to get
>> > in a
>> > > >> > battle
>> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
>> patches
>> > > >> COULD
>> > > >> > be
>> > > >> > > >> applied to both in the manner you described.
>> > > >> > > >>
>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
>> tickets
>> > > >> marked
>> > > >> > > for
>> > > >> > > >> 0.5.1 had the right patches in the support branch, and some
>> > > didn't,
>> > > >> > so I
>> > > >> > > >> think "lesson learned". I do like in the apache
>> infrastructure
>> > > that
>> > > >> if
>> > > >> > > >> commits have the appropriate ticket in their commit message,
>> > the
>> > > >> jira
>> > > >> > > will
>> > > >> > > >> have the list of commits and branches those commits were
>> > applies
>> > > to.
>> > > >> > > >> However, I think we may need to revisit commit message
>> > > "hygiene" if
>> > > >> > we
>> > > >> > > >> relied on this instead of more manual review.
>> > > >> > > >>
>> > > >> > > >>
>> > > >> > > >>
>> > > >> > > >>
>> > > >> > > >>
>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
>> > > >> r.p.miskin@gmail.com
>> > > >> > >
>> > > >> > > >> wrote:
>> > > >> > > >>
>> > > >> > > >>> Hi,
>> > > >> > > >>>
>> > > >> > > >>> On a couple of work projects we found that the approach of
>> > > >> > > cherry-picking
>> > > >> > > >>> commits can lead to an unnecessarily complicated history
>> where
>> > > the
>> > > >> > same
>> > > >> > > >>> piece of work appears as multiple separate commits on
>> > different
>> > > >> > > branches.
>> > > >> > > >>> This can then make it hard to be confident that a bug fix
>> has
>> > > been
>> > > >> > > >> applied
>> > > >> > > >>> to all relevant branches. We found that it works better to
>> aim
>> > > to
>> > > >> > > commit
>> > > >> > > >>> changes to the lowest applicable branch, and then regularly
>> > > merge
>> > > >> > those
>> > > >> > > >>> branches to master. This approach is based on the git-flow
>> > > model (
>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
>> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
>> > > >> > > >>>
>> > > >> > > >>> Looking at the repo there are already a few commits that
>> are
>> > > >> > duplicated
>> > > >> > > >> on
>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d only
>> occur
>> > on
>> > > >> > 0.5.1,
>> > > >> > > >> and
>> > > >> > > >>> then that branch would get merged to master.
>> > > >> > > >>>
>> > > >> > > >>> Having the merge commits from the support branch to master
>> > > makes it
>> > > >> > > >>> explicit in the git history that all bug fixes (and
>> associated
>> > > >> tests)
>> > > >> > > >> have
>> > > >> > > >>> been pulled through to master.
>> > > >> > > >>>
>> > > >> > > >>> Cheers,
>> > > >> > > >>> Richard
>> > > >> > > >>>
>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com>
>> > wrote:
>> > > >> > > >>>>
>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see
>> if
>> > > you
>> > > >> > > agree:
>> > > >> > > >>>>
>> > > >> > > >>>> 1.) Commits merged to master today are destined for the
>> next
>> > > minor
>> > > >> > > >>> release,
>> > > >> > > >>>> currently 0.6.0, by default?
>> > > >> > > >>>>
>> > > >> > > >>>> By default, commits to master will be released in the next
>> > > major
>> > > >> or
>> > > >> > > >> minor
>> > > >> > > >>>> release. No commits are included in incremental/patch
>> > > releases by
>> > > >> > > >>> default.
>> > > >> > > >>>>
>> > > >> > > >>>>
>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
>> > > >> > > >>>>
>> > > >> > > >>>> support/0.5.x will be maintained until the first of the
>> > > following
>> > > >> > > >> events:
>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major release
>> > > line)
>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
>> release
>> > > >> lines
>> > > >> > up
>> > > >> > > >> to
>> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in
>> that
>> > > >> line")
>> > > >> > > >>>>
>> > > >> > > >>>> But additional support might be available by special
>> request.
>> > > >> > > >>>>
>> > > >> > > >>>>
>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined for a
>> > future
>> > > >> major
>> > > >> > > >>>> release stored? Is it visible anywhere?
>> > > >> > > >>>>
>> > > >> > > >>>> I suppose Jira tickets targeting the next major release
>> > > >> > > >>> could/should/would
>> > > >> > > >>>> (do?) push branches. That seems weak in the face of a
>> > probable
>> > > >> > > >> stampede
>> > > >> > > >>>> towards the fire exit of a major release, but it's a
>> start.
>> > > I'm
>> > > >> not
>> > > >> > > >>> aware
>> > > >> > > >>>> of any great solutions here, certainly not for an
>> open-source
>> > > >> > project.
>> > > >> > > >>>>
>> > > >> > > >>>>
>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
>> > joe.witt@gmail.com>
>> > > >> > wrote:
>> > > >> > > >>>>
>> > > >> > > >>>>> James,
>> > > >> > > >>>>>
>> > > >> > > >>>>> These are great questions to frame and test the model. So
>> > > let's
>> > > >> > > >>>>> attempt to address them agains the model.
>> > > >> > > >>>>>
>> > > >> > > >>>>> Here is the language for that model at this time:
>> > > >> > > >>>>>
>> > > >> > > >>>>> - 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'
>> > > >> > > >>>>>
>> > > >> > > >>>>> So with those above let's review 1 through 5 in turn.
>> > > >> > > >>>>>
>> > > >> > > >>>>> 1.) Commits merged to master today are destined for the
>> next
>> > > >> minor
>> > > >> > > >>>>> release, currently 0.6.0, by default?
>> > > >> > > >>>>>
>> > > >> > > >>>>> Master is for whatever is the most leading edge release
>> line
>> > > >> > working
>> > > >> > > >>>>> toward the next release. At the time that a minor
>> release
>> > > occurs
>> > > >> > > >>>>> against that release line then it branches off into a
>> > > >> support/x.y.*
>> > > >> > > >>>>> branch for any further efforts against it.
>> > > >> > > >>>>>
>> > > >> > > >>>>> 2.) Is master always open for merging new code, or are
>> there
>> > > >> > > >>> restrictions
>> > > >> > > >>>>> before or after releases?
>> > > >> > > >>>>>
>> > > >> > > >>>>> I believe master would be always open for new code. From
>> > some
>> > > >> > point
>> > > >> > > >>>>> at which a release is considered feature complete then
>> > further
>> > > >> > > feature
>> > > >> > > >>>>> enhancements need to go on master as part of the next
>> > release
>> > > >> > effort.
>> > > >> > > >>>>>
>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
>> > > >> > > >>>>>
>> > > >> > > >>>>> The most recent minor release line of a major line will
>> be
>> > > >> > supported
>> > > >> > > >>>>> for up to one year from whenever it was released where
>> > > support is
>> > > >> > for
>> > > >> > > >>>>> bug fixes for security or data loss related items.
>> Releases
>> > > for
>> > > >> > > older
>> > > >> > > >>>>> minor lines should be considered on a case by case basis
>> and
>> > > if
>> > > >> > > >>>>> requested. Otherwise the basic premise is the train is
>> > moving
>> > > >> > > >>>>> forward.
>> > > >> > > >>>>>
>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined for a
>> > future
>> > > >> > major
>> > > >> > > >>>>> release stored? Is it visible anywhere?
>> > > >> > > >>>>>
>> > > >> > > >>>>> It must be visible. It should be placed into a branch
>> until
>> > > such
>> > > >> > > >>>>> time that it is ready to become the new master. That
>> time
>> > > would
>> > > >> be
>> > > >> > > >>>>> when the next release will be for that line. When I
>> think
>> > > about
>> > > >> > this
>> > > >> > > >>>>> against the stated model we could probably tweak the
>> wording
>> > > to
>> > > >> > > better
>> > > >> > > >>>>> articulate that. I think it was what was meant with
>> 'when
>> > > master
>> > > >> > has
>> > > >> > > >>>>> no releases we will backport...' but that is unclear.
>> > > >> > > >>>>>
>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
>> > > eligible
>> > > >> to
>> > > >> > be
>> > > >> > > >>>>> backported only to the last minor release in the 0.x
>> line,
>> > or
>> > > to
>> > > >> > all
>> > > >> > > >>> minor
>> > > >> > > >>>>> releases in the 0.x line?
>> > > >> > > >>>>>
>> > > >> > > >>>>> Only to the most recent minor release of any still
>> supported
>> > > >> major
>> > > >> > > >>>>> line. However, the catch of 'case by case' determination
>> > for
>> > > >> older
>> > > >> > > >>>>> minor lines is still in play. Basically if someone
>> requests
>> > > it
>> > > >> and
>> > > >> > > >>>>> can get enough momentum for it then it should be no
>> problem
>> > to
>> > > >> > > produce
>> > > >> > > >>>>> such a release.
>> > > >> > > >>>>>
>> > > >> > > >>>>> Thanks
>> > > >> > > >>>>> Joe
>> > > >> > > >>>>>
>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
>> > jvwing@gmail.com
>> > > >
>> > > >> > > wrote:
>> > > >> > > >>>>>> I have some rhetorical questions for discussion of the
>> > > branching
>> > > >> > > >> model:
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> 1.) Commits merged to master today are destined for the
>> > next
>> > > >> minor
>> > > >> > > >>>>> release,
>> > > >> > > >>>>>> currently 0.6.0, by default?
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> 2.) Is master always open for merging new code, or are
>> > there
>> > > >> > > >>> restrictions
>> > > >> > > >>>>>> before or after releases?
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a
>> > > future
>> > > >> > major
>> > > >> > > >>>>>> release stored? Is it visible anywhere?
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would
>> > > eligible
>> > > >> to
>> > > >> > > be
>> > > >> > > >>>>>> backported only to the last minor release in the 0.x
>> line,
>> > > or to
>> > > >> > all
>> > > >> > > >>>>> minor
>> > > >> > > >>>>>> releases in the 0.x line?
>> > > >> > > >>>>>>
>> > > >> > > >>>>>>
>> > > >> > > >>>>>>
>> > > >> > > >>>>>>
>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
>> > > joe.witt@gmail.com>
>> > > >> > > >> wrote:
>> > > >> > > >>>>>>
>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it
>> more
>> > > >> toward
>> > > >> > a
>> > > >> > > >>>>>>> proposal as we're at a point now where we need to start
>> > > >> executing
>> > > >> > > >> some
>> > > >> > > >>>>>>> of these approaches. We're actually already seeing it
>> > take
>> > > >> form
>> > > >> > in
>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch (which
>> is
>> > for
>> > > >> > 0.6.0
>> > > >> > > >> at
>> > > >> > > >>>>>>> this point).
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>>> The proposal then for Git processes based on the other
>> > > thread
>> > > >> [1]
>> > > >> > > >>>>>>> where we outline a support model:
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>>> - 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
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>>> [1]
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>
>> > > >> > > >>>
>> > > >> > > >>
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>>> Thanks
>> > > >> > > >>>>>>> Joe
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
>> > > joe.witt@gmail.com>
>> > > >> > > >> wrote:
>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
>> discuss
>> > > >> > specific
>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
>> consensus
>> > > >> > > discussion
>> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
>> kicked
>> > > off a
>> > > >> > > >>>>>>>> discussion back at that level.
>> > > >> > > >>>>>>>>
>> > > >> > > >>>>>>>>
>> > > >> > > >>>>>>>>
>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
>> > > trkurc@gmail.com>
>> > > >> > > >> wrote:
>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the
>> > > plugins
>> > > >> > that
>> > > >> > > >> are
>> > > >> > > >>>>>>> used.
>> > > >> > > >>>>>>>>> I have worked on some other projects (unfortunately
>> not
>> > > open
>> > > >> > > >> source)
>> > > >> > > >>>>>>> that
>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a
>> > > plugin.
>> > > >> > > Nice
>> > > >> > > >>>>> side
>> > > >> > > >>>>>>>>> effect is that I believe this got me better at using
>> > git,
>> > > and
>> > > >> > > >>>>> generally
>> > > >> > > >>>>>>> we
>> > > >> > > >>>>>>>>> all got better at managing merge pain.
>> > > >> > > >>>>>>>>>
>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're operating
>> > the
>> > > way
>> > > >> > we
>> > > >> > > >> are
>> > > >> > > >>>>>>> now is
>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a
>> > > patch is
>> > > >> > > "can
>> > > >> > > >>> be
>> > > >> > > >>>>>>>>> merged into master", and we have our friend Travis to
>> > make
>> > > >> this
>> > > >> > > >> even
>> > > >> > > >>>>>>> easier
>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a
>> > > bugfix
>> > > >> is
>> > > >> > > >>>>> "patch
>> > > >> > > >>>>>>>>> needs to be able to apply onto the current release in
>> > > >> progress,
>> > > >> > > >>>>> master,
>> > > >> > > >>>>>>> and
>> > > >> > > >>>>>>>>> several other versions we're supporting, with
>> possibly
>> > > >> > > drastically
>> > > >> > > >>>>>>>>> different code", well then things get interesting.
>> > > >> > > >>>>>>>>>
>> > > >> > > >>>>>>>>>
>> > > >> > > >>>>>>>>>
>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>> > > >> > > >>>>>>> bimargulies@gmail.com>
>> > > >> > > >>>>>>>>> wrote:
>> > > >> > > >>>>>>>>>
>> > > >> > > >>>>>>>>>> The issue tracker
>> > > >> > > >>>>>>>>>>
>> > > >> > > >>>>>>>>>>
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>
>> > > >> > > >>>
>> > > >> > > >>
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
>> > > >> > > >>>>>>>>>>
>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It
>> worked
>> > > >> great,
>> > > >> > > >>>>> until
>> > > >> > > >>>>>>> it
>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable,
>> > merge
>> > > >> > > >> problems.
>> > > >> > > >>>>> No
>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
>> > > >> > > >>>>>>>>>>>
>> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
>> > > >> > > >>>>>>>>>>>
>> > > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>> > > >> > > >>>>>>>>>>>
>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
>> > > >> > adam@adamtaft.com
>> > > >> > > >
>> > > >> > > >>>>>>> wrote:
>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using it
>> in
>> > > >> > > >> combination
>> > > >> > > >>>>>>> with
>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are
>> > > tracking
>> > > >> > > >>>>> closely
>> > > >> > > >>>>>>> with
>> > > >> > > >>>>>>>>>> the
>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
>> doesn't
>> > > keep
>> > > >> > the
>> > > >> > > >> pom
>> > > >> > > >>>>>>>>>> version
>> > > >> > > >>>>>>>>>>>> updated with the git release names.
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
>> releases
>> > > and
>> > > >> > tags
>> > > >> > > >>>>>>>>>> synchronized
>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it
>> > needs
>> > > to
>> > > >> be
>> > > >> > > >>>>>>> approached
>> > > >> > > >>>>>>>>>>>> with tools that are available through maven rather
>> > than
>> > > >> from
>> > > >> > > >> git.
>> > > >> > > >>>>>>> The
>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
>> directly
>> > > help
>> > > >> > > deal
>> > > >> > > >>>>> with
>> > > >> > > >>>>>>>>>> this
>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a
>> maven
>> > > tool.
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
>> > jgitflow
>> > > [1]
>> > > >> > > >>>>> plugin,
>> > > >> > > >>>>>>> which
>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow
>> model
>> > > for a
>> > > >> > > >> maven
>> > > >> > > >>>>>>>>>> project.
>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it
>> > > insists
>> > > >> > > that
>> > > >> > > >>>>> the
>> > > >> > > >>>>>>>>>> master
>> > > >> > > >>>>>>>>>>>> branch is strictly used for published release tags
>> > (as
>> > > per
>> > > >> > the
>> > > >> > > >>>>>>> strict
>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
>> reference
>> > > to
>> > > >> how
>> > > >> > > >> some
>> > > >> > > >>>>>>>>>> plugins
>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization
>> > > issue.
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
>> > > >> > > >>>>> thadguidry@gmail.com
>> > > >> > > >>>>>>>>
>> > > >> > > >>>>>>>>>> wrote:
>> > > >> > > >>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow.
>> Your
>> > > >> Master
>> > > >> > > >>>>> become
>> > > >> > > >>>>>>>>>> primary
>> > > >> > > >>>>>>>>>>>>> development of next release (with feature
>> branches
>> > > off of
>> > > >> > > >> it)..
>> > > >> > > >>>>>>> while
>> > > >> > > >>>>>>>>>> you
>> > > >> > > >>>>>>>>>>>>> continue to have release branches that can have
>> hot
>> > > fix
>> > > >> > > >> branches
>> > > >> > > >>>>>>> off of
>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch
>> ! -
>> > > bad
>> > > >> > > >>>>> practice !
>> > > >> > > >>>>>>> )
>> > > >> > > >>>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy
>> for
>> > > >> > everyone
>> > > >> > > >> to
>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
>> > > >> > understanding.
>> > > >> > > >> Its
>> > > >> > > >>>>>>> really
>> > > >> > > >>>>>>>>>>>>> that easy.
>> > > >> > > >>>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>>
>> http://danielkummer.github.io/git-flow-cheatsheet/
>> > > >> > > >>>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using
>> git-flow
>> > ...
>> > > >> and
>> > > >> > > >> tools
>> > > >> > > >>>>>>> like
>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
>> > > Git-flow
>> > > >> > > either
>> > > >> > > >>>>>>> built
>> > > >> > > >>>>>>>>>> in or
>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on the
>> > > command
>> > > >> > > >> line,
>> > > >> > > >>>>>>> then
>> > > >> > > >>>>>>>>>> that
>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the
>> above
>> > > link.
>> > > >> > > >>>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>>>> Thad
>> > > >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>> > > >> > > >>>>>>>>>>>>>
>> > > >> > > >>>>>>>>>>
>> > > >> > > >>>>>>>
>> > > >> > > >>>>>
>> > > >> > > >>>
>> > > >> > > >>>
>> > > >> > > >>
>> > > >> > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > >
>> >
>>
>
>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
Matt,
I agree that the PRs would need to be merged to both baselines at
contribution time. If the contribution applies cleanly the reviewer could
certainly handle the commit themselves. However, if additional code changes
are required because the baselines have diverged, the contributor would
probably need to submit another PR. This additional effort should only be
necessary until we're able to perform the first 1.x release.
Aldrin,
I definitely understand your thoughts regarding (1) and (2). This is why I
wanted to pose the options before just jumping into one approach vs the
other. I personally prefer the GitHub style PR process. I realize this is
more cumbersome but hopefully the number of conflicts should be small as
folks are already starting to focus their efforts on the framework for 1.x.
Matt
On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri <al...@gmail.com> wrote:
> I think I prefer option 2 considering, what may be the incorrect
> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be easier.
> Based on outstanding PRs/Patches in conjunction with release cadence there
> will be more 0.x releases planned. Until we reached the point where the
> first 1.x release is in sight, I think (2) makes sense just from minimizing
> impedance where the majority of effort will occur (new/updated extensions)
> and then switching to (1) when we are scheduling 1.x as next (exclusive of
> any patch builds). This seems to work out when I try to reason about it,
> but admittedly, am coming at this heavily from my own anecdotal perspective
> given my flow of reviewing.
>
> Matt, excellent points to consider.
>
> Do not want to go too much on a tangent from the current conversation, but
> I think we need to harness automation as much as possible. Not sure Travis
> can do this or do so easily (short of two PRs) and this may arguably shift
> things in favor of patches and the model that the other ASF projects
> utilize with buildbot. Getting as much done asynchronously for us is
> obviously important but we also have to strive to avoid a contrib process
> that is too cumbersome as well.
>
> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com>
> wrote:
>
> > I like option 1 as well.
> >
> > In the case where a fix is to be put into both branches, will the
> developer
> > be responsible for issuing 2 PRs / patches, one against each branch? This
> > would help in the case that the PR/patch against 0.x won't merge cleanly
> > into master; however the reviewer(s) would need to make sure there were
> no
> > breaking changes as a result of the manual merge to master. An
> alternative
> > is that the reviewer(s) do the forward-port, which I don't think is a
> good
> > idea. However the reviewer would need to make sure the PR(s) are against
> > the correct branch. For example, all current PRs would need to be
> > "backported" to the new 0.x branch.
> >
> > Also, I would think the PRs/patches need to be merged at the same time
> (or
> > soon), to avoid regressions (i.e. a bug fix going into 0.x but getting
> > forgotten/missed for 1.x).
> >
> > Thoughts? Thanks,
> > Matt
> >
> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > I too prefer option 1
> > >
> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu> wrote:
> > > > I agree with Tony on option 1. I think it makes sense for master to
> > be
> > > > the most "advanced" branch. New features will then always be applied
> > to
> > > > master, and optionally to other branches for older version support as
> > > > applicable / desired.
> > > >
> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com> wrote:
> > > >
> > > >> I like option 1
> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com>
> > > wrote:
> > > >>
> > > >> > Hello,
> > > >> >
> > > >> > With NiFi 0.6.0 officially released and our support strategy
> defined
> > > [1],
> > > >> > I'd like to revisit and propose some options for supporting both a
> > 1.x
> > > >> > branch and 0.x branch concurrently. We need an official place
> where
> > > these
> > > >> > efforts can be worked, contributed to, and collaborated with the
> > > >> community.
> > > >> > I've already created a 1.x branch as a temporary place for this
> > > codebase
> > > >> to
> > > >> > live until we agree to an approach.
> > > >> >
> > > >> > Either option I'm proposing will require PRs/contributions/patches
> > to
> > > be
> > > >> > applied to both branches as applicable. This means that the
> > > contributor
> > > >> or
> > > >> > the reviewer will need to be able to apply the commits in both
> > places
> > > if
> > > >> > it's necessary. For instance, framework code has already started
> > > >> diverging
> > > >> > from the current master so any framework change may not need to be
> > > >> applied
> > > >> > to both if the changeset is not applicable to the 1.x baseline.
> > > >> >
> > > >> > The only question at the moment is what master will refer to.
> > > >> >
> > > >> > 1) Create a branch for 0.x and allow master to become the 1.x
> > baseline
> > > >> > going forward. Future 0.x releases will be performed from the 0.x
> > > branch.
> > > >> > 2) Continuing working on the 1.x branch as is. Allow master to
> > > continue
> > > >> to
> > > >> > servicing 0.x releases. Once a 1.x release is made, create the 0.x
> > > branch
> > > >> > and then allow master to service 1.x releases.
> > > >> >
> > > >> > In short, when do we want master to point to the 1.x baseline?
> When
> > > >> should
> > > >> > we create a branch where 0.x releases will be made from.
> Regardless,
> > > >> > contributions will need to be performed to both places as
> > applicable.
> > > >> >
> > > >> > Thanks.
> > > >> >
> > > >> > Matt
> > > >> >
> > > >> > [1]
> > > >> >
> > > >> >
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > > >> >
> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> > > r.p.miskin@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > I guess it will depend how much change is expected on the
> > > maintenance
> > > >> > > branches,
> > > >> > > but if you want every change in the maintenance branch to go
> into
> > > the
> > > >> > > main-line branch then there is little difference from a conflict
> > > point
> > > >> of
> > > >> > > view
> > > >> > > between a series of cherry-picks and a merge.
> > > >> > >
> > > >> > > Either way, it is just another approach to consider. There’s
> more
> > > than
> > > >> > one
> > > >> > > way to do it, and I suspect there isn’t any solution that makes
> it
> > > >> > trivial.
> > > >> > >
> > > >> > > Cheers,
> > > >> > > Richard
> > > >> > >
> > > >> > >
> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com>
> > > wrote:
> > > >> > > >
> > > >> > > > On board with Tony's points. I think the realities of merging
> > in
> > > >> > > practice
> > > >> > > > when that "breaking point" of sorts occurs will make the
> > > complexity
> > > >> and
> > > >> > > > overhead quite difficult and maybe even more error prone than
> > the
> > > >> > cherry
> > > >> > > > picking approach with some additional guidelines. When the
> > > codebase
> > > >> > > > drastically changes, the merge conflicts could be quite severe
> > and
> > > >> > > without
> > > >> > > > a good knowledge of each part of the codebase involved during
> > that
> > > >> > > process,
> > > >> > > > a committer may introduce regressions.
> > > >> > > >
> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com>
> > > wrote:
> > > >> > > >
> > > >> > > >> the reason I like applying patches to both lines is that once
> > > code
> > > >> > > begins
> > > >> > > >> to diverge, cleanly merging into one codebase can be
> > impossible.
> > > >> > having
> > > >> > > >> good practices for managing patches and where they apply is
> > > >> paramount
> > > >> > > for
> > > >> > > >> success.
> > > >> > > >>
> > > >> > > >> I expect that divergence to happen with 1.x. I wanted to get
> > in a
> > > >> > battle
> > > >> > > >> rhythm of sorts of managing multiple lines, even if the
> patches
> > > >> COULD
> > > >> > be
> > > >> > > >> applied to both in the manner you described.
> > > >> > > >>
> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure that
> tickets
> > > >> marked
> > > >> > > for
> > > >> > > >> 0.5.1 had the right patches in the support branch, and some
> > > didn't,
> > > >> > so I
> > > >> > > >> think "lesson learned". I do like in the apache
> infrastructure
> > > that
> > > >> if
> > > >> > > >> commits have the appropriate ticket in their commit message,
> > the
> > > >> jira
> > > >> > > will
> > > >> > > >> have the list of commits and branches those commits were
> > applies
> > > to.
> > > >> > > >> However, I think we may need to revisit commit message
> > > "hygiene" if
> > > >> > we
> > > >> > > >> relied on this instead of more manual review.
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> > > >> r.p.miskin@gmail.com
> > > >> > >
> > > >> > > >> wrote:
> > > >> > > >>
> > > >> > > >>> Hi,
> > > >> > > >>>
> > > >> > > >>> On a couple of work projects we found that the approach of
> > > >> > > cherry-picking
> > > >> > > >>> commits can lead to an unnecessarily complicated history
> where
> > > the
> > > >> > same
> > > >> > > >>> piece of work appears as multiple separate commits on
> > different
> > > >> > > branches.
> > > >> > > >>> This can then make it hard to be confident that a bug fix
> has
> > > been
> > > >> > > >> applied
> > > >> > > >>> to all relevant branches. We found that it works better to
> aim
> > > to
> > > >> > > commit
> > > >> > > >>> changes to the lowest applicable branch, and then regularly
> > > merge
> > > >> > those
> > > >> > > >>> branches to master. This approach is based on the git-flow
> > > model (
> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> > > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> > > >> > > >>>
> > > >> > > >>> Looking at the repo there are already a few commits that are
> > > >> > duplicated
> > > >> > > >> on
> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d only
> occur
> > on
> > > >> > 0.5.1,
> > > >> > > >> and
> > > >> > > >>> then that branch would get merged to master.
> > > >> > > >>>
> > > >> > > >>> Having the merge commits from the support branch to master
> > > makes it
> > > >> > > >>> explicit in the git history that all bug fixes (and
> associated
> > > >> tests)
> > > >> > > >> have
> > > >> > > >>> been pulled through to master.
> > > >> > > >>>
> > > >> > > >>> Cheers,
> > > >> > > >>> Richard
> > > >> > > >>>
> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com>
> > wrote:
> > > >> > > >>>>
> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see
> if
> > > you
> > > >> > > agree:
> > > >> > > >>>>
> > > >> > > >>>> 1.) Commits merged to master today are destined for the
> next
> > > minor
> > > >> > > >>> release,
> > > >> > > >>>> currently 0.6.0, by default?
> > > >> > > >>>>
> > > >> > > >>>> By default, commits to master will be released in the next
> > > major
> > > >> or
> > > >> > > >> minor
> > > >> > > >>>> release. No commits are included in incremental/patch
> > > releases by
> > > >> > > >>> default.
> > > >> > > >>>>
> > > >> > > >>>>
> > > >> > > >>>> 3.) How long will support/0.5.x be maintained?
> > > >> > > >>>>
> > > >> > > >>>> support/0.5.x will be maintained until the first of the
> > > following
> > > >> > > >> events:
> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major release
> > > line)
> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous major
> release
> > > >> lines
> > > >> > up
> > > >> > > >> to
> > > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in
> that
> > > >> line")
> > > >> > > >>>>
> > > >> > > >>>> But additional support might be available by special
> request.
> > > >> > > >>>>
> > > >> > > >>>>
> > > >> > > >>>> 4.) Where is compatibility-breaking code destined for a
> > future
> > > >> major
> > > >> > > >>>> release stored? Is it visible anywhere?
> > > >> > > >>>>
> > > >> > > >>>> I suppose Jira tickets targeting the next major release
> > > >> > > >>> could/should/would
> > > >> > > >>>> (do?) push branches. That seems weak in the face of a
> > probable
> > > >> > > >> stampede
> > > >> > > >>>> towards the fire exit of a major release, but it's a start.
> > > I'm
> > > >> not
> > > >> > > >>> aware
> > > >> > > >>>> of any great solutions here, certainly not for an
> open-source
> > > >> > project.
> > > >> > > >>>>
> > > >> > > >>>>
> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
> > joe.witt@gmail.com>
> > > >> > wrote:
> > > >> > > >>>>
> > > >> > > >>>>> James,
> > > >> > > >>>>>
> > > >> > > >>>>> These are great questions to frame and test the model. So
> > > let's
> > > >> > > >>>>> attempt to address them agains the model.
> > > >> > > >>>>>
> > > >> > > >>>>> Here is the language for that model at this time:
> > > >> > > >>>>>
> > > >> > > >>>>> - 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'
> > > >> > > >>>>>
> > > >> > > >>>>> So with those above let's review 1 through 5 in turn.
> > > >> > > >>>>>
> > > >> > > >>>>> 1.) Commits merged to master today are destined for the
> next
> > > >> minor
> > > >> > > >>>>> release, currently 0.6.0, by default?
> > > >> > > >>>>>
> > > >> > > >>>>> Master is for whatever is the most leading edge release
> line
> > > >> > working
> > > >> > > >>>>> toward the next release. At the time that a minor release
> > > occurs
> > > >> > > >>>>> against that release line then it branches off into a
> > > >> support/x.y.*
> > > >> > > >>>>> branch for any further efforts against it.
> > > >> > > >>>>>
> > > >> > > >>>>> 2.) Is master always open for merging new code, or are
> there
> > > >> > > >>> restrictions
> > > >> > > >>>>> before or after releases?
> > > >> > > >>>>>
> > > >> > > >>>>> I believe master would be always open for new code. From
> > some
> > > >> > point
> > > >> > > >>>>> at which a release is considered feature complete then
> > further
> > > >> > > feature
> > > >> > > >>>>> enhancements need to go on master as part of the next
> > release
> > > >> > effort.
> > > >> > > >>>>>
> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> > > >> > > >>>>>
> > > >> > > >>>>> The most recent minor release line of a major line will be
> > > >> > supported
> > > >> > > >>>>> for up to one year from whenever it was released where
> > > support is
> > > >> > for
> > > >> > > >>>>> bug fixes for security or data loss related items.
> Releases
> > > for
> > > >> > > older
> > > >> > > >>>>> minor lines should be considered on a case by case basis
> and
> > > if
> > > >> > > >>>>> requested. Otherwise the basic premise is the train is
> > moving
> > > >> > > >>>>> forward.
> > > >> > > >>>>>
> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined for a
> > future
> > > >> > major
> > > >> > > >>>>> release stored? Is it visible anywhere?
> > > >> > > >>>>>
> > > >> > > >>>>> It must be visible. It should be placed into a branch
> until
> > > such
> > > >> > > >>>>> time that it is ready to become the new master. That time
> > > would
> > > >> be
> > > >> > > >>>>> when the next release will be for that line. When I think
> > > about
> > > >> > this
> > > >> > > >>>>> against the stated model we could probably tweak the
> wording
> > > to
> > > >> > > better
> > > >> > > >>>>> articulate that. I think it was what was meant with 'when
> > > master
> > > >> > has
> > > >> > > >>>>> no releases we will backport...' but that is unclear.
> > > >> > > >>>>>
> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
> > > eligible
> > > >> to
> > > >> > be
> > > >> > > >>>>> backported only to the last minor release in the 0.x line,
> > or
> > > to
> > > >> > all
> > > >> > > >>> minor
> > > >> > > >>>>> releases in the 0.x line?
> > > >> > > >>>>>
> > > >> > > >>>>> Only to the most recent minor release of any still
> supported
> > > >> major
> > > >> > > >>>>> line. However, the catch of 'case by case' determination
> > for
> > > >> older
> > > >> > > >>>>> minor lines is still in play. Basically if someone
> requests
> > > it
> > > >> and
> > > >> > > >>>>> can get enough momentum for it then it should be no
> problem
> > to
> > > >> > > produce
> > > >> > > >>>>> such a release.
> > > >> > > >>>>>
> > > >> > > >>>>> Thanks
> > > >> > > >>>>> Joe
> > > >> > > >>>>>
> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
> > jvwing@gmail.com
> > > >
> > > >> > > wrote:
> > > >> > > >>>>>> I have some rhetorical questions for discussion of the
> > > branching
> > > >> > > >> model:
> > > >> > > >>>>>>
> > > >> > > >>>>>> 1.) Commits merged to master today are destined for the
> > next
> > > >> minor
> > > >> > > >>>>> release,
> > > >> > > >>>>>> currently 0.6.0, by default?
> > > >> > > >>>>>>
> > > >> > > >>>>>> 2.) Is master always open for merging new code, or are
> > there
> > > >> > > >>> restrictions
> > > >> > > >>>>>> before or after releases?
> > > >> > > >>>>>>
> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> > > >> > > >>>>>>
> > > >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a
> > > future
> > > >> > major
> > > >> > > >>>>>> release stored? Is it visible anywhere?
> > > >> > > >>>>>>
> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would
> > > eligible
> > > >> to
> > > >> > > be
> > > >> > > >>>>>> backported only to the last minor release in the 0.x
> line,
> > > or to
> > > >> > all
> > > >> > > >>>>> minor
> > > >> > > >>>>>> releases in the 0.x line?
> > > >> > > >>>>>>
> > > >> > > >>>>>>
> > > >> > > >>>>>>
> > > >> > > >>>>>>
> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> > > joe.witt@gmail.com>
> > > >> > > >> wrote:
> > > >> > > >>>>>>
> > > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it
> more
> > > >> toward
> > > >> > a
> > > >> > > >>>>>>> proposal as we're at a point now where we need to start
> > > >> executing
> > > >> > > >> some
> > > >> > > >>>>>>> of these approaches. We're actually already seeing it
> > take
> > > >> form
> > > >> > in
> > > >> > > >>>>>>> the support/0.5.x branch and the master branch (which is
> > for
> > > >> > 0.6.0
> > > >> > > >> at
> > > >> > > >>>>>>> this point).
> > > >> > > >>>>>>>
> > > >> > > >>>>>>> The proposal then for Git processes based on the other
> > > thread
> > > >> [1]
> > > >> > > >>>>>>> where we outline a support model:
> > > >> > > >>>>>>>
> > > >> > > >>>>>>> - 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
> > > >> > > >>>>>>>
> > > >> > > >>>>>>> [1]
> > > >> > > >>>>>>>
> > > >> > > >>>>>
> > > >> > > >>>
> > > >> > > >>
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > > >> > > >>>>>>>
> > > >> > > >>>>>>> Thanks
> > > >> > > >>>>>>> Joe
> > > >> > > >>>>>>>
> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> > > joe.witt@gmail.com>
> > > >> > > >> wrote:
> > > >> > > >>>>>>>> I don't want to kill this thread. It is good to
> discuss
> > > >> > specific
> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some
> consensus
> > > >> > > discussion
> > > >> > > >>>>>>>> around Tony's original intent (as I read it). So
> kicked
> > > off a
> > > >> > > >>>>>>>> discussion back at that level.
> > > >> > > >>>>>>>>
> > > >> > > >>>>>>>>
> > > >> > > >>>>>>>>
> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> > > trkurc@gmail.com>
> > > >> > > >> wrote:
> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the
> > > plugins
> > > >> > that
> > > >> > > >> are
> > > >> > > >>>>>>> used.
> > > >> > > >>>>>>>>> I have worked on some other projects (unfortunately
> not
> > > open
> > > >> > > >> source)
> > > >> > > >>>>>>> that
> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a
> > > plugin.
> > > >> > > Nice
> > > >> > > >>>>> side
> > > >> > > >>>>>>>>> effect is that I believe this got me better at using
> > git,
> > > and
> > > >> > > >>>>> generally
> > > >> > > >>>>>>> we
> > > >> > > >>>>>>>>> all got better at managing merge pain.
> > > >> > > >>>>>>>>>
> > > >> > > >>>>>>>>> On merge problems, I think the reason we're operating
> > the
> > > way
> > > >> > we
> > > >> > > >> are
> > > >> > > >>>>>>> now is
> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a
> > > patch is
> > > >> > > "can
> > > >> > > >>> be
> > > >> > > >>>>>>>>> merged into master", and we have our friend Travis to
> > make
> > > >> this
> > > >> > > >> even
> > > >> > > >>>>>>> easier
> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a
> > > bugfix
> > > >> is
> > > >> > > >>>>> "patch
> > > >> > > >>>>>>>>> needs to be able to apply onto the current release in
> > > >> progress,
> > > >> > > >>>>> master,
> > > >> > > >>>>>>> and
> > > >> > > >>>>>>>>> several other versions we're supporting, with possibly
> > > >> > > drastically
> > > >> > > >>>>>>>>> different code", well then things get interesting.
> > > >> > > >>>>>>>>>
> > > >> > > >>>>>>>>>
> > > >> > > >>>>>>>>>
> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> > > >> > > >>>>>>> bimargulies@gmail.com>
> > > >> > > >>>>>>>>> wrote:
> > > >> > > >>>>>>>>>
> > > >> > > >>>>>>>>>> The issue tracker
> > > >> > > >>>>>>>>>>
> > > >> > > >>>>>>>>>>
> > > >> > > >>>>>>>
> > > >> > > >>>>>
> > > >> > > >>>
> > > >> > > >>
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > > >> > > >>>>>>>>>> might also prove useful in evaluating it.
> > > >> > > >>>>>>>>>>
> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> > > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It
> worked
> > > >> great,
> > > >> > > >>>>> until
> > > >> > > >>>>>>> it
> > > >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable,
> > merge
> > > >> > > >> problems.
> > > >> > > >>>>> No
> > > >> > > >>>>>>>>>>> one seemed to be maintaining it.
> > > >> > > >>>>>>>>>>>
> > > >> > > >>>>>>>>>>> There's a new offering in this dept:
> > > >> > > >>>>>>>>>>>
> > > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> > > >> > > >>>>>>>>>>>
> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> > > >> > adam@adamtaft.com
> > > >> > > >
> > > >> > > >>>>>>> wrote:
> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using it
> in
> > > >> > > >> combination
> > > >> > > >>>>>>> with
> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are
> > > tracking
> > > >> > > >>>>> closely
> > > >> > > >>>>>>> with
> > > >> > > >>>>>>>>>> the
> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own,
> doesn't
> > > keep
> > > >> > the
> > > >> > > >> pom
> > > >> > > >>>>>>>>>> version
> > > >> > > >>>>>>>>>>>> updated with the git release names.
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>> Because of the general importance of keeping
> releases
> > > and
> > > >> > tags
> > > >> > > >>>>>>>>>> synchronized
> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it
> > needs
> > > to
> > > >> be
> > > >> > > >>>>>>> approached
> > > >> > > >>>>>>>>>>>> with tools that are available through maven rather
> > than
> > > >> from
> > > >> > > >> git.
> > > >> > > >>>>>>> The
> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't
> directly
> > > help
> > > >> > > deal
> > > >> > > >>>>> with
> > > >> > > >>>>>>>>>> this
> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven
> > > tool.
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
> > jgitflow
> > > [1]
> > > >> > > >>>>> plugin,
> > > >> > > >>>>>>> which
> > > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow
> model
> > > for a
> > > >> > > >> maven
> > > >> > > >>>>>>>>>> project.
> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it
> > > insists
> > > >> > > that
> > > >> > > >>>>> the
> > > >> > > >>>>>>>>>> master
> > > >> > > >>>>>>>>>>>> branch is strictly used for published release tags
> > (as
> > > per
> > > >> > the
> > > >> > > >>>>>>> strict
> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in
> reference
> > > to
> > > >> how
> > > >> > > >> some
> > > >> > > >>>>>>>>>> plugins
> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization
> > > issue.
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> > > >> > > >>>>> thadguidry@gmail.com
> > > >> > > >>>>>>>>
> > > >> > > >>>>>>>>>> wrote:
> > > >> > > >>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow.
> Your
> > > >> Master
> > > >> > > >>>>> become
> > > >> > > >>>>>>>>>> primary
> > > >> > > >>>>>>>>>>>>> development of next release (with feature branches
> > > off of
> > > >> > > >> it)..
> > > >> > > >>>>>>> while
> > > >> > > >>>>>>>>>> you
> > > >> > > >>>>>>>>>>>>> continue to have release branches that can have
> hot
> > > fix
> > > >> > > >> branches
> > > >> > > >>>>>>> off of
> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch !
> -
> > > bad
> > > >> > > >>>>> practice !
> > > >> > > >>>>>>> )
> > > >> > > >>>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy
> for
> > > >> > everyone
> > > >> > > >> to
> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
> > > >> > understanding.
> > > >> > > >> Its
> > > >> > > >>>>>>> really
> > > >> > > >>>>>>>>>>>>> that easy.
> > > >> > > >>>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>>
> http://danielkummer.github.io/git-flow-cheatsheet/
> > > >> > > >>>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow
> > ...
> > > >> and
> > > >> > > >> tools
> > > >> > > >>>>>>> like
> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
> > > Git-flow
> > > >> > > either
> > > >> > > >>>>>>> built
> > > >> > > >>>>>>>>>> in or
> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on the
> > > command
> > > >> > > >> line,
> > > >> > > >>>>>>> then
> > > >> > > >>>>>>>>>> that
> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the above
> > > link.
> > > >> > > >>>>>>>>>>>>>
> > > >> > > >>>>>>>>>>>>> Thad
> > > >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> > > >> > > >>>>>>>>>>>>>
> > > >> > > >>>>>>>>>>
> > > >> > > >>>>>>>
> > > >> > > >>>>>
> > > >> > > >>>
> > > >> > > >>>
> > > >> > > >>
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
Re: [DISCUSS] git branching model
Posted by Aldrin Piri <al...@gmail.com>.
I think I prefer option 2 considering, what may be the incorrect
assumption, that rebasing 1.x on 0.x / pushing into 1.x would be easier.
Based on outstanding PRs/Patches in conjunction with release cadence there
will be more 0.x releases planned. Until we reached the point where the
first 1.x release is in sight, I think (2) makes sense just from minimizing
impedance where the majority of effort will occur (new/updated extensions)
and then switching to (1) when we are scheduling 1.x as next (exclusive of
any patch builds). This seems to work out when I try to reason about it,
but admittedly, am coming at this heavily from my own anecdotal perspective
given my flow of reviewing.
Matt, excellent points to consider.
Do not want to go too much on a tangent from the current conversation, but
I think we need to harness automation as much as possible. Not sure Travis
can do this or do so easily (short of two PRs) and this may arguably shift
things in favor of patches and the model that the other ASF projects
utilize with buildbot. Getting as much done asynchronously for us is
obviously important but we also have to strive to avoid a contrib process
that is too cumbersome as well.
On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess <ma...@gmail.com> wrote:
> I like option 1 as well.
>
> In the case where a fix is to be put into both branches, will the developer
> be responsible for issuing 2 PRs / patches, one against each branch? This
> would help in the case that the PR/patch against 0.x won't merge cleanly
> into master; however the reviewer(s) would need to make sure there were no
> breaking changes as a result of the manual merge to master. An alternative
> is that the reviewer(s) do the forward-port, which I don't think is a good
> idea. However the reviewer would need to make sure the PR(s) are against
> the correct branch. For example, all current PRs would need to be
> "backported" to the new 0.x branch.
>
> Also, I would think the PRs/patches need to be merged at the same time (or
> soon), to avoid regressions (i.e. a bug fix going into 0.x but getting
> forgotten/missed for 1.x).
>
> Thoughts? Thanks,
> Matt
>
> On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > I too prefer option 1
> >
> > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu> wrote:
> > > I agree with Tony on option 1. I think it makes sense for master to
> be
> > > the most "advanced" branch. New features will then always be applied
> to
> > > master, and optionally to other branches for older version support as
> > > applicable / desired.
> > >
> > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com> wrote:
> > >
> > >> I like option 1
> > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com>
> > wrote:
> > >>
> > >> > Hello,
> > >> >
> > >> > With NiFi 0.6.0 officially released and our support strategy defined
> > [1],
> > >> > I'd like to revisit and propose some options for supporting both a
> 1.x
> > >> > branch and 0.x branch concurrently. We need an official place where
> > these
> > >> > efforts can be worked, contributed to, and collaborated with the
> > >> community.
> > >> > I've already created a 1.x branch as a temporary place for this
> > codebase
> > >> to
> > >> > live until we agree to an approach.
> > >> >
> > >> > Either option I'm proposing will require PRs/contributions/patches
> to
> > be
> > >> > applied to both branches as applicable. This means that the
> > contributor
> > >> or
> > >> > the reviewer will need to be able to apply the commits in both
> places
> > if
> > >> > it's necessary. For instance, framework code has already started
> > >> diverging
> > >> > from the current master so any framework change may not need to be
> > >> applied
> > >> > to both if the changeset is not applicable to the 1.x baseline.
> > >> >
> > >> > The only question at the moment is what master will refer to.
> > >> >
> > >> > 1) Create a branch for 0.x and allow master to become the 1.x
> baseline
> > >> > going forward. Future 0.x releases will be performed from the 0.x
> > branch.
> > >> > 2) Continuing working on the 1.x branch as is. Allow master to
> > continue
> > >> to
> > >> > servicing 0.x releases. Once a 1.x release is made, create the 0.x
> > branch
> > >> > and then allow master to service 1.x releases.
> > >> >
> > >> > In short, when do we want master to point to the 1.x baseline? When
> > >> should
> > >> > we create a branch where 0.x releases will be made from. Regardless,
> > >> > contributions will need to be performed to both places as
> applicable.
> > >> >
> > >> > Thanks.
> > >> >
> > >> > Matt
> > >> >
> > >> > [1]
> > >> >
> > >> >
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >> >
> > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> > r.p.miskin@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > I guess it will depend how much change is expected on the
> > maintenance
> > >> > > branches,
> > >> > > but if you want every change in the maintenance branch to go into
> > the
> > >> > > main-line branch then there is little difference from a conflict
> > point
> > >> of
> > >> > > view
> > >> > > between a series of cherry-picks and a merge.
> > >> > >
> > >> > > Either way, it is just another approach to consider. There’s more
> > than
> > >> > one
> > >> > > way to do it, and I suspect there isn’t any solution that makes it
> > >> > trivial.
> > >> > >
> > >> > > Cheers,
> > >> > > Richard
> > >> > >
> > >> > >
> > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com>
> > wrote:
> > >> > > >
> > >> > > > On board with Tony's points. I think the realities of merging
> in
> > >> > > practice
> > >> > > > when that "breaking point" of sorts occurs will make the
> > complexity
> > >> and
> > >> > > > overhead quite difficult and maybe even more error prone than
> the
> > >> > cherry
> > >> > > > picking approach with some additional guidelines. When the
> > codebase
> > >> > > > drastically changes, the merge conflicts could be quite severe
> and
> > >> > > without
> > >> > > > a good knowledge of each part of the codebase involved during
> that
> > >> > > process,
> > >> > > > a committer may introduce regressions.
> > >> > > >
> > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com>
> > wrote:
> > >> > > >
> > >> > > >> the reason I like applying patches to both lines is that once
> > code
> > >> > > begins
> > >> > > >> to diverge, cleanly merging into one codebase can be
> impossible.
> > >> > having
> > >> > > >> good practices for managing patches and where they apply is
> > >> paramount
> > >> > > for
> > >> > > >> success.
> > >> > > >>
> > >> > > >> I expect that divergence to happen with 1.x. I wanted to get
> in a
> > >> > battle
> > >> > > >> rhythm of sorts of managing multiple lines, even if the patches
> > >> COULD
> > >> > be
> > >> > > >> applied to both in the manner you described.
> > >> > > >>
> > >> > > >> Joe W and I did a wee bit of scrambling to ensure that tickets
> > >> marked
> > >> > > for
> > >> > > >> 0.5.1 had the right patches in the support branch, and some
> > didn't,
> > >> > so I
> > >> > > >> think "lesson learned". I do like in the apache infrastructure
> > that
> > >> if
> > >> > > >> commits have the appropriate ticket in their commit message,
> the
> > >> jira
> > >> > > will
> > >> > > >> have the list of commits and branches those commits were
> applies
> > to.
> > >> > > >> However, I think we may need to revisit commit message
> > "hygiene" if
> > >> > we
> > >> > > >> relied on this instead of more manual review.
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> > >> r.p.miskin@gmail.com
> > >> > >
> > >> > > >> wrote:
> > >> > > >>
> > >> > > >>> Hi,
> > >> > > >>>
> > >> > > >>> On a couple of work projects we found that the approach of
> > >> > > cherry-picking
> > >> > > >>> commits can lead to an unnecessarily complicated history where
> > the
> > >> > same
> > >> > > >>> piece of work appears as multiple separate commits on
> different
> > >> > > branches.
> > >> > > >>> This can then make it hard to be confident that a bug fix has
> > been
> > >> > > >> applied
> > >> > > >>> to all relevant branches. We found that it works better to aim
> > to
> > >> > > commit
> > >> > > >>> changes to the lowest applicable branch, and then regularly
> > merge
> > >> > those
> > >> > > >>> branches to master. This approach is based on the git-flow
> > model (
> > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> > >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> > >> > > >>>
> > >> > > >>> Looking at the repo there are already a few commits that are
> > >> > duplicated
> > >> > > >> on
> > >> > > >>> master and 0.5.1. Using the model I suggest they’d only occur
> on
> > >> > 0.5.1,
> > >> > > >> and
> > >> > > >>> then that branch would get merged to master.
> > >> > > >>>
> > >> > > >>> Having the merge commits from the support branch to master
> > makes it
> > >> > > >>> explicit in the git history that all bug fixes (and associated
> > >> tests)
> > >> > > >> have
> > >> > > >>> been pulled through to master.
> > >> > > >>>
> > >> > > >>> Cheers,
> > >> > > >>> Richard
> > >> > > >>>
> > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com>
> wrote:
> > >> > > >>>>
> > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see if
> > you
> > >> > > agree:
> > >> > > >>>>
> > >> > > >>>> 1.) Commits merged to master today are destined for the next
> > minor
> > >> > > >>> release,
> > >> > > >>>> currently 0.6.0, by default?
> > >> > > >>>>
> > >> > > >>>> By default, commits to master will be released in the next
> > major
> > >> or
> > >> > > >> minor
> > >> > > >>>> release. No commits are included in incremental/patch
> > releases by
> > >> > > >>> default.
> > >> > > >>>>
> > >> > > >>>>
> > >> > > >>>> 3.) How long will support/0.5.x be maintained?
> > >> > > >>>>
> > >> > > >>>> support/0.5.x will be maintained until the first of the
> > following
> > >> > > >> events:
> > >> > > >>>> a.) 0.6.0 is released (next minor release in major release
> > line)
> > >> > > >>>> b.) One year after 1.0.0 is released ("previous major release
> > >> lines
> > >> > up
> > >> > > >> to
> > >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in that
> > >> line")
> > >> > > >>>>
> > >> > > >>>> But additional support might be available by special request.
> > >> > > >>>>
> > >> > > >>>>
> > >> > > >>>> 4.) Where is compatibility-breaking code destined for a
> future
> > >> major
> > >> > > >>>> release stored? Is it visible anywhere?
> > >> > > >>>>
> > >> > > >>>> I suppose Jira tickets targeting the next major release
> > >> > > >>> could/should/would
> > >> > > >>>> (do?) push branches. That seems weak in the face of a
> probable
> > >> > > >> stampede
> > >> > > >>>> towards the fire exit of a major release, but it's a start.
> > I'm
> > >> not
> > >> > > >>> aware
> > >> > > >>>> of any great solutions here, certainly not for an open-source
> > >> > project.
> > >> > > >>>>
> > >> > > >>>>
> > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <
> joe.witt@gmail.com>
> > >> > wrote:
> > >> > > >>>>
> > >> > > >>>>> James,
> > >> > > >>>>>
> > >> > > >>>>> These are great questions to frame and test the model. So
> > let's
> > >> > > >>>>> attempt to address them agains the model.
> > >> > > >>>>>
> > >> > > >>>>> Here is the language for that model at this time:
> > >> > > >>>>>
> > >> > > >>>>> - 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'
> > >> > > >>>>>
> > >> > > >>>>> So with those above let's review 1 through 5 in turn.
> > >> > > >>>>>
> > >> > > >>>>> 1.) Commits merged to master today are destined for the next
> > >> minor
> > >> > > >>>>> release, currently 0.6.0, by default?
> > >> > > >>>>>
> > >> > > >>>>> Master is for whatever is the most leading edge release line
> > >> > working
> > >> > > >>>>> toward the next release. At the time that a minor release
> > occurs
> > >> > > >>>>> against that release line then it branches off into a
> > >> support/x.y.*
> > >> > > >>>>> branch for any further efforts against it.
> > >> > > >>>>>
> > >> > > >>>>> 2.) Is master always open for merging new code, or are there
> > >> > > >>> restrictions
> > >> > > >>>>> before or after releases?
> > >> > > >>>>>
> > >> > > >>>>> I believe master would be always open for new code. From
> some
> > >> > point
> > >> > > >>>>> at which a release is considered feature complete then
> further
> > >> > > feature
> > >> > > >>>>> enhancements need to go on master as part of the next
> release
> > >> > effort.
> > >> > > >>>>>
> > >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> > >> > > >>>>>
> > >> > > >>>>> The most recent minor release line of a major line will be
> > >> > supported
> > >> > > >>>>> for up to one year from whenever it was released where
> > support is
> > >> > for
> > >> > > >>>>> bug fixes for security or data loss related items. Releases
> > for
> > >> > > older
> > >> > > >>>>> minor lines should be considered on a case by case basis and
> > if
> > >> > > >>>>> requested. Otherwise the basic premise is the train is
> moving
> > >> > > >>>>> forward.
> > >> > > >>>>>
> > >> > > >>>>> 4.) Where is compatibility-breaking code destined for a
> future
> > >> > major
> > >> > > >>>>> release stored? Is it visible anywhere?
> > >> > > >>>>>
> > >> > > >>>>> It must be visible. It should be placed into a branch until
> > such
> > >> > > >>>>> time that it is ready to become the new master. That time
> > would
> > >> be
> > >> > > >>>>> when the next release will be for that line. When I think
> > about
> > >> > this
> > >> > > >>>>> against the stated model we could probably tweak the wording
> > to
> > >> > > better
> > >> > > >>>>> articulate that. I think it was what was meant with 'when
> > master
> > >> > has
> > >> > > >>>>> no releases we will backport...' but that is unclear.
> > >> > > >>>>>
> > >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
> > eligible
> > >> to
> > >> > be
> > >> > > >>>>> backported only to the last minor release in the 0.x line,
> or
> > to
> > >> > all
> > >> > > >>> minor
> > >> > > >>>>> releases in the 0.x line?
> > >> > > >>>>>
> > >> > > >>>>> Only to the most recent minor release of any still supported
> > >> major
> > >> > > >>>>> line. However, the catch of 'case by case' determination
> for
> > >> older
> > >> > > >>>>> minor lines is still in play. Basically if someone requests
> > it
> > >> and
> > >> > > >>>>> can get enough momentum for it then it should be no problem
> to
> > >> > > produce
> > >> > > >>>>> such a release.
> > >> > > >>>>>
> > >> > > >>>>> Thanks
> > >> > > >>>>> Joe
> > >> > > >>>>>
> > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <
> jvwing@gmail.com
> > >
> > >> > > wrote:
> > >> > > >>>>>> I have some rhetorical questions for discussion of the
> > branching
> > >> > > >> model:
> > >> > > >>>>>>
> > >> > > >>>>>> 1.) Commits merged to master today are destined for the
> next
> > >> minor
> > >> > > >>>>> release,
> > >> > > >>>>>> currently 0.6.0, by default?
> > >> > > >>>>>>
> > >> > > >>>>>> 2.) Is master always open for merging new code, or are
> there
> > >> > > >>> restrictions
> > >> > > >>>>>> before or after releases?
> > >> > > >>>>>>
> > >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> > >> > > >>>>>>
> > >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a
> > future
> > >> > major
> > >> > > >>>>>> release stored? Is it visible anywhere?
> > >> > > >>>>>>
> > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would
> > eligible
> > >> to
> > >> > > be
> > >> > > >>>>>> backported only to the last minor release in the 0.x line,
> > or to
> > >> > all
> > >> > > >>>>> minor
> > >> > > >>>>>> releases in the 0.x line?
> > >> > > >>>>>>
> > >> > > >>>>>>
> > >> > > >>>>>>
> > >> > > >>>>>>
> > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> > joe.witt@gmail.com>
> > >> > > >> wrote:
> > >> > > >>>>>>
> > >> > > >>>>>>> Given the discussion has stalled i'd like to turn it more
> > >> toward
> > >> > a
> > >> > > >>>>>>> proposal as we're at a point now where we need to start
> > >> executing
> > >> > > >> some
> > >> > > >>>>>>> of these approaches. We're actually already seeing it
> take
> > >> form
> > >> > in
> > >> > > >>>>>>> the support/0.5.x branch and the master branch (which is
> for
> > >> > 0.6.0
> > >> > > >> at
> > >> > > >>>>>>> this point).
> > >> > > >>>>>>>
> > >> > > >>>>>>> The proposal then for Git processes based on the other
> > thread
> > >> [1]
> > >> > > >>>>>>> where we outline a support model:
> > >> > > >>>>>>>
> > >> > > >>>>>>> - 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
> > >> > > >>>>>>>
> > >> > > >>>>>>> [1]
> > >> > > >>>>>>>
> > >> > > >>>>>
> > >> > > >>>
> > >> > > >>
> > >> > >
> > >> >
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >> > > >>>>>>>
> > >> > > >>>>>>> Thanks
> > >> > > >>>>>>> Joe
> > >> > > >>>>>>>
> > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> > joe.witt@gmail.com>
> > >> > > >> wrote:
> > >> > > >>>>>>>> I don't want to kill this thread. It is good to discuss
> > >> > specific
> > >> > > >>>>>>>> tooling/procedures. But I do want to get some consensus
> > >> > > discussion
> > >> > > >>>>>>>> around Tony's original intent (as I read it). So kicked
> > off a
> > >> > > >>>>>>>> discussion back at that level.
> > >> > > >>>>>>>>
> > >> > > >>>>>>>>
> > >> > > >>>>>>>>
> > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> > trkurc@gmail.com>
> > >> > > >> wrote:
> > >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the
> > plugins
> > >> > that
> > >> > > >> are
> > >> > > >>>>>>> used.
> > >> > > >>>>>>>>> I have worked on some other projects (unfortunately not
> > open
> > >> > > >> source)
> > >> > > >>>>>>> that
> > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a
> > plugin.
> > >> > > Nice
> > >> > > >>>>> side
> > >> > > >>>>>>>>> effect is that I believe this got me better at using
> git,
> > and
> > >> > > >>>>> generally
> > >> > > >>>>>>> we
> > >> > > >>>>>>>>> all got better at managing merge pain.
> > >> > > >>>>>>>>>
> > >> > > >>>>>>>>> On merge problems, I think the reason we're operating
> the
> > way
> > >> > we
> > >> > > >> are
> > >> > > >>>>>>> now is
> > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a
> > patch is
> > >> > > "can
> > >> > > >>> be
> > >> > > >>>>>>>>> merged into master", and we have our friend Travis to
> make
> > >> this
> > >> > > >> even
> > >> > > >>>>>>> easier
> > >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a
> > bugfix
> > >> is
> > >> > > >>>>> "patch
> > >> > > >>>>>>>>> needs to be able to apply onto the current release in
> > >> progress,
> > >> > > >>>>> master,
> > >> > > >>>>>>> and
> > >> > > >>>>>>>>> several other versions we're supporting, with possibly
> > >> > > drastically
> > >> > > >>>>>>>>> different code", well then things get interesting.
> > >> > > >>>>>>>>>
> > >> > > >>>>>>>>>
> > >> > > >>>>>>>>>
> > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> > >> > > >>>>>>> bimargulies@gmail.com>
> > >> > > >>>>>>>>> wrote:
> > >> > > >>>>>>>>>
> > >> > > >>>>>>>>>> The issue tracker
> > >> > > >>>>>>>>>>
> > >> > > >>>>>>>>>>
> > >> > > >>>>>>>
> > >> > > >>>>>
> > >> > > >>>
> > >> > > >>
> > >> > >
> > >> >
> > >>
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > >> > > >>>>>>>>>> might also prove useful in evaluating it.
> > >> > > >>>>>>>>>>
> > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> > >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked
> > >> great,
> > >> > > >>>>> until
> > >> > > >>>>>>> it
> > >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable,
> merge
> > >> > > >> problems.
> > >> > > >>>>> No
> > >> > > >>>>>>>>>>> one seemed to be maintaining it.
> > >> > > >>>>>>>>>>>
> > >> > > >>>>>>>>>>> There's a new offering in this dept:
> > >> > > >>>>>>>>>>>
> > >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> > >> > > >>>>>>>>>>>
> > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> > >> > adam@adamtaft.com
> > >> > > >
> > >> > > >>>>>>> wrote:
> > >> > > >>>>>>>>>>>> One of the harder things with gitflow is using it in
> > >> > > >> combination
> > >> > > >>>>>>> with
> > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are
> > tracking
> > >> > > >>>>> closely
> > >> > > >>>>>>> with
> > >> > > >>>>>>>>>> the
> > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't
> > keep
> > >> > the
> > >> > > >> pom
> > >> > > >>>>>>>>>> version
> > >> > > >>>>>>>>>>>> updated with the git release names.
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>> Because of the general importance of keeping releases
> > and
> > >> > tags
> > >> > > >>>>>>>>>> synchronized
> > >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it
> needs
> > to
> > >> be
> > >> > > >>>>>>> approached
> > >> > > >>>>>>>>>>>> with tools that are available through maven rather
> than
> > >> from
> > >> > > >> git.
> > >> > > >>>>>>> The
> > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly
> > help
> > >> > > deal
> > >> > > >>>>> with
> > >> > > >>>>>>>>>> this
> > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven
> > tool.
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>> I've been using, with reasonable success, the
> jgitflow
> > [1]
> > >> > > >>>>> plugin,
> > >> > > >>>>>>> which
> > >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow model
> > for a
> > >> > > >> maven
> > >> > > >>>>>>>>>> project.
> > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it
> > insists
> > >> > > that
> > >> > > >>>>> the
> > >> > > >>>>>>>>>> master
> > >> > > >>>>>>>>>>>> branch is strictly used for published release tags
> (as
> > per
> > >> > the
> > >> > > >>>>>>> strict
> > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference
> > to
> > >> how
> > >> > > >> some
> > >> > > >>>>>>>>>> plugins
> > >> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization
> > issue.
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> > >> > > >>>>> thadguidry@gmail.com
> > >> > > >>>>>>>>
> > >> > > >>>>>>>>>> wrote:
> > >> > > >>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your
> > >> Master
> > >> > > >>>>> become
> > >> > > >>>>>>>>>> primary
> > >> > > >>>>>>>>>>>>> development of next release (with feature branches
> > off of
> > >> > > >> it)..
> > >> > > >>>>>>> while
> > >> > > >>>>>>>>>> you
> > >> > > >>>>>>>>>>>>> continue to have release branches that can have hot
> > fix
> > >> > > >> branches
> > >> > > >>>>>>> off of
> > >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch ! -
> > bad
> > >> > > >>>>> practice !
> > >> > > >>>>>>> )
> > >> > > >>>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for
> > >> > everyone
> > >> > > >> to
> > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
> > >> > understanding.
> > >> > > >> Its
> > >> > > >>>>>>> really
> > >> > > >>>>>>>>>>>>> that easy.
> > >> > > >>>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> > >> > > >>>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow
> ...
> > >> and
> > >> > > >> tools
> > >> > > >>>>>>> like
> > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
> > Git-flow
> > >> > > either
> > >> > > >>>>>>> built
> > >> > > >>>>>>>>>> in or
> > >> > > >>>>>>>>>>>>> plugin available now. If you want to live on the
> > command
> > >> > > >> line,
> > >> > > >>>>>>> then
> > >> > > >>>>>>>>>> that
> > >> > > >>>>>>>>>>>>> is handled easily by the instructions in the above
> > link.
> > >> > > >>>>>>>>>>>>>
> > >> > > >>>>>>>>>>>>> Thad
> > >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> > >> > > >>>>>>>>>>>>>
> > >> > > >>>>>>>>>>
> > >> > > >>>>>>>
> > >> > > >>>>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> >
>
Re: [DISCUSS] git branching model
Posted by Matt Burgess <ma...@gmail.com>.
I like option 1 as well.
In the case where a fix is to be put into both branches, will the developer
be responsible for issuing 2 PRs / patches, one against each branch? This
would help in the case that the PR/patch against 0.x won't merge cleanly
into master; however the reviewer(s) would need to make sure there were no
breaking changes as a result of the manual merge to master. An alternative
is that the reviewer(s) do the forward-port, which I don't think is a good
idea. However the reviewer would need to make sure the PR(s) are against
the correct branch. For example, all current PRs would need to be
"backported" to the new 0.x branch.
Also, I would think the PRs/patches need to be merged at the same time (or
soon), to avoid regressions (i.e. a bug fix going into 0.x but getting
forgotten/missed for 1.x).
Thoughts? Thanks,
Matt
On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <jo...@gmail.com> wrote:
> I too prefer option 1
>
> On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu> wrote:
> > I agree with Tony on option 1. I think it makes sense for master to be
> > the most "advanced" branch. New features will then always be applied to
> > master, and optionally to other branches for older version support as
> > applicable / desired.
> >
> > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com> wrote:
> >
> >> I like option 1
> >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com>
> wrote:
> >>
> >> > Hello,
> >> >
> >> > With NiFi 0.6.0 officially released and our support strategy defined
> [1],
> >> > I'd like to revisit and propose some options for supporting both a 1.x
> >> > branch and 0.x branch concurrently. We need an official place where
> these
> >> > efforts can be worked, contributed to, and collaborated with the
> >> community.
> >> > I've already created a 1.x branch as a temporary place for this
> codebase
> >> to
> >> > live until we agree to an approach.
> >> >
> >> > Either option I'm proposing will require PRs/contributions/patches to
> be
> >> > applied to both branches as applicable. This means that the
> contributor
> >> or
> >> > the reviewer will need to be able to apply the commits in both places
> if
> >> > it's necessary. For instance, framework code has already started
> >> diverging
> >> > from the current master so any framework change may not need to be
> >> applied
> >> > to both if the changeset is not applicable to the 1.x baseline.
> >> >
> >> > The only question at the moment is what master will refer to.
> >> >
> >> > 1) Create a branch for 0.x and allow master to become the 1.x baseline
> >> > going forward. Future 0.x releases will be performed from the 0.x
> branch.
> >> > 2) Continuing working on the 1.x branch as is. Allow master to
> continue
> >> to
> >> > servicing 0.x releases. Once a 1.x release is made, create the 0.x
> branch
> >> > and then allow master to service 1.x releases.
> >> >
> >> > In short, when do we want master to point to the 1.x baseline? When
> >> should
> >> > we create a branch where 0.x releases will be made from. Regardless,
> >> > contributions will need to be performed to both places as applicable.
> >> >
> >> > Thanks.
> >> >
> >> > Matt
> >> >
> >> > [1]
> >> >
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >> >
> >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <
> r.p.miskin@gmail.com>
> >> > wrote:
> >> >
> >> > > I guess it will depend how much change is expected on the
> maintenance
> >> > > branches,
> >> > > but if you want every change in the maintenance branch to go into
> the
> >> > > main-line branch then there is little difference from a conflict
> point
> >> of
> >> > > view
> >> > > between a series of cherry-picks and a merge.
> >> > >
> >> > > Either way, it is just another approach to consider. There’s more
> than
> >> > one
> >> > > way to do it, and I suspect there isn’t any solution that makes it
> >> > trivial.
> >> > >
> >> > > Cheers,
> >> > > Richard
> >> > >
> >> > >
> >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com>
> wrote:
> >> > > >
> >> > > > On board with Tony's points. I think the realities of merging in
> >> > > practice
> >> > > > when that "breaking point" of sorts occurs will make the
> complexity
> >> and
> >> > > > overhead quite difficult and maybe even more error prone than the
> >> > cherry
> >> > > > picking approach with some additional guidelines. When the
> codebase
> >> > > > drastically changes, the merge conflicts could be quite severe and
> >> > > without
> >> > > > a good knowledge of each part of the codebase involved during that
> >> > > process,
> >> > > > a committer may introduce regressions.
> >> > > >
> >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com>
> wrote:
> >> > > >
> >> > > >> the reason I like applying patches to both lines is that once
> code
> >> > > begins
> >> > > >> to diverge, cleanly merging into one codebase can be impossible.
> >> > having
> >> > > >> good practices for managing patches and where they apply is
> >> paramount
> >> > > for
> >> > > >> success.
> >> > > >>
> >> > > >> I expect that divergence to happen with 1.x. I wanted to get in a
> >> > battle
> >> > > >> rhythm of sorts of managing multiple lines, even if the patches
> >> COULD
> >> > be
> >> > > >> applied to both in the manner you described.
> >> > > >>
> >> > > >> Joe W and I did a wee bit of scrambling to ensure that tickets
> >> marked
> >> > > for
> >> > > >> 0.5.1 had the right patches in the support branch, and some
> didn't,
> >> > so I
> >> > > >> think "lesson learned". I do like in the apache infrastructure
> that
> >> if
> >> > > >> commits have the appropriate ticket in their commit message, the
> >> jira
> >> > > will
> >> > > >> have the list of commits and branches those commits were applies
> to.
> >> > > >> However, I think we may need to revisit commit message
> "hygiene" if
> >> > we
> >> > > >> relied on this instead of more manual review.
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> >> r.p.miskin@gmail.com
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >>> Hi,
> >> > > >>>
> >> > > >>> On a couple of work projects we found that the approach of
> >> > > cherry-picking
> >> > > >>> commits can lead to an unnecessarily complicated history where
> the
> >> > same
> >> > > >>> piece of work appears as multiple separate commits on different
> >> > > branches.
> >> > > >>> This can then make it hard to be confident that a bug fix has
> been
> >> > > >> applied
> >> > > >>> to all relevant branches. We found that it works better to aim
> to
> >> > > commit
> >> > > >>> changes to the lowest applicable branch, and then regularly
> merge
> >> > those
> >> > > >>> branches to master. This approach is based on the git-flow
> model (
> >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> >> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> >> > > >>>
> >> > > >>> Looking at the repo there are already a few commits that are
> >> > duplicated
> >> > > >> on
> >> > > >>> master and 0.5.1. Using the model I suggest they’d only occur on
> >> > 0.5.1,
> >> > > >> and
> >> > > >>> then that branch would get merged to master.
> >> > > >>>
> >> > > >>> Having the merge commits from the support branch to master
> makes it
> >> > > >>> explicit in the git history that all bug fixes (and associated
> >> tests)
> >> > > >> have
> >> > > >>> been pulled through to master.
> >> > > >>>
> >> > > >>> Cheers,
> >> > > >>> Richard
> >> > > >>>
> >> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> >> > > >>>>
> >> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see if
> you
> >> > > agree:
> >> > > >>>>
> >> > > >>>> 1.) Commits merged to master today are destined for the next
> minor
> >> > > >>> release,
> >> > > >>>> currently 0.6.0, by default?
> >> > > >>>>
> >> > > >>>> By default, commits to master will be released in the next
> major
> >> or
> >> > > >> minor
> >> > > >>>> release. No commits are included in incremental/patch
> releases by
> >> > > >>> default.
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> 3.) How long will support/0.5.x be maintained?
> >> > > >>>>
> >> > > >>>> support/0.5.x will be maintained until the first of the
> following
> >> > > >> events:
> >> > > >>>> a.) 0.6.0 is released (next minor release in major release
> line)
> >> > > >>>> b.) One year after 1.0.0 is released ("previous major release
> >> lines
> >> > up
> >> > > >> to
> >> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in that
> >> line")
> >> > > >>>>
> >> > > >>>> But additional support might be available by special request.
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> 4.) Where is compatibility-breaking code destined for a future
> >> major
> >> > > >>>> release stored? Is it visible anywhere?
> >> > > >>>>
> >> > > >>>> I suppose Jira tickets targeting the next major release
> >> > > >>> could/should/would
> >> > > >>>> (do?) push branches. That seems weak in the face of a probable
> >> > > >> stampede
> >> > > >>>> towards the fire exit of a major release, but it's a start.
> I'm
> >> not
> >> > > >>> aware
> >> > > >>>> of any great solutions here, certainly not for an open-source
> >> > project.
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com>
> >> > wrote:
> >> > > >>>>
> >> > > >>>>> James,
> >> > > >>>>>
> >> > > >>>>> These are great questions to frame and test the model. So
> let's
> >> > > >>>>> attempt to address them agains the model.
> >> > > >>>>>
> >> > > >>>>> Here is the language for that model at this time:
> >> > > >>>>>
> >> > > >>>>> - 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'
> >> > > >>>>>
> >> > > >>>>> So with those above let's review 1 through 5 in turn.
> >> > > >>>>>
> >> > > >>>>> 1.) Commits merged to master today are destined for the next
> >> minor
> >> > > >>>>> release, currently 0.6.0, by default?
> >> > > >>>>>
> >> > > >>>>> Master is for whatever is the most leading edge release line
> >> > working
> >> > > >>>>> toward the next release. At the time that a minor release
> occurs
> >> > > >>>>> against that release line then it branches off into a
> >> support/x.y.*
> >> > > >>>>> branch for any further efforts against it.
> >> > > >>>>>
> >> > > >>>>> 2.) Is master always open for merging new code, or are there
> >> > > >>> restrictions
> >> > > >>>>> before or after releases?
> >> > > >>>>>
> >> > > >>>>> I believe master would be always open for new code. From some
> >> > point
> >> > > >>>>> at which a release is considered feature complete then further
> >> > > feature
> >> > > >>>>> enhancements need to go on master as part of the next release
> >> > effort.
> >> > > >>>>>
> >> > > >>>>> 3.) How long will support/0.5.x be maintained?
> >> > > >>>>>
> >> > > >>>>> The most recent minor release line of a major line will be
> >> > supported
> >> > > >>>>> for up to one year from whenever it was released where
> support is
> >> > for
> >> > > >>>>> bug fixes for security or data loss related items. Releases
> for
> >> > > older
> >> > > >>>>> minor lines should be considered on a case by case basis and
> if
> >> > > >>>>> requested. Otherwise the basic premise is the train is moving
> >> > > >>>>> forward.
> >> > > >>>>>
> >> > > >>>>> 4.) Where is compatibility-breaking code destined for a future
> >> > major
> >> > > >>>>> release stored? Is it visible anywhere?
> >> > > >>>>>
> >> > > >>>>> It must be visible. It should be placed into a branch until
> such
> >> > > >>>>> time that it is ready to become the new master. That time
> would
> >> be
> >> > > >>>>> when the next release will be for that line. When I think
> about
> >> > this
> >> > > >>>>> against the stated model we could probably tweak the wording
> to
> >> > > better
> >> > > >>>>> articulate that. I think it was what was meant with 'when
> master
> >> > has
> >> > > >>>>> no releases we will backport...' but that is unclear.
> >> > > >>>>>
> >> > > >>>>> 5.) A critical data/security bug found after 1.0 would
> eligible
> >> to
> >> > be
> >> > > >>>>> backported only to the last minor release in the 0.x line, or
> to
> >> > all
> >> > > >>> minor
> >> > > >>>>> releases in the 0.x line?
> >> > > >>>>>
> >> > > >>>>> Only to the most recent minor release of any still supported
> >> major
> >> > > >>>>> line. However, the catch of 'case by case' determination for
> >> older
> >> > > >>>>> minor lines is still in play. Basically if someone requests
> it
> >> and
> >> > > >>>>> can get enough momentum for it then it should be no problem to
> >> > > produce
> >> > > >>>>> such a release.
> >> > > >>>>>
> >> > > >>>>> Thanks
> >> > > >>>>> Joe
> >> > > >>>>>
> >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jvwing@gmail.com
> >
> >> > > wrote:
> >> > > >>>>>> I have some rhetorical questions for discussion of the
> branching
> >> > > >> model:
> >> > > >>>>>>
> >> > > >>>>>> 1.) Commits merged to master today are destined for the next
> >> minor
> >> > > >>>>> release,
> >> > > >>>>>> currently 0.6.0, by default?
> >> > > >>>>>>
> >> > > >>>>>> 2.) Is master always open for merging new code, or are there
> >> > > >>> restrictions
> >> > > >>>>>> before or after releases?
> >> > > >>>>>>
> >> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> >> > > >>>>>>
> >> > > >>>>>> 4.) Where is compatibility-breaking code destined for a
> future
> >> > major
> >> > > >>>>>> release stored? Is it visible anywhere?
> >> > > >>>>>>
> >> > > >>>>>> 5.) A critical data/security bug found after 1.0 would
> eligible
> >> to
> >> > > be
> >> > > >>>>>> backported only to the last minor release in the 0.x line,
> or to
> >> > all
> >> > > >>>>> minor
> >> > > >>>>>> releases in the 0.x line?
> >> > > >>>>>>
> >> > > >>>>>>
> >> > > >>>>>>
> >> > > >>>>>>
> >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <
> joe.witt@gmail.com>
> >> > > >> wrote:
> >> > > >>>>>>
> >> > > >>>>>>> Given the discussion has stalled i'd like to turn it more
> >> toward
> >> > a
> >> > > >>>>>>> proposal as we're at a point now where we need to start
> >> executing
> >> > > >> some
> >> > > >>>>>>> of these approaches. We're actually already seeing it take
> >> form
> >> > in
> >> > > >>>>>>> the support/0.5.x branch and the master branch (which is for
> >> > 0.6.0
> >> > > >> at
> >> > > >>>>>>> this point).
> >> > > >>>>>>>
> >> > > >>>>>>> The proposal then for Git processes based on the other
> thread
> >> [1]
> >> > > >>>>>>> where we outline a support model:
> >> > > >>>>>>>
> >> > > >>>>>>> - 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
> >> > > >>>>>>>
> >> > > >>>>>>> [1]
> >> > > >>>>>>>
> >> > > >>>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >> > > >>>>>>>
> >> > > >>>>>>> Thanks
> >> > > >>>>>>> Joe
> >> > > >>>>>>>
> >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <
> joe.witt@gmail.com>
> >> > > >> wrote:
> >> > > >>>>>>>> I don't want to kill this thread. It is good to discuss
> >> > specific
> >> > > >>>>>>>> tooling/procedures. But I do want to get some consensus
> >> > > discussion
> >> > > >>>>>>>> around Tony's original intent (as I read it). So kicked
> off a
> >> > > >>>>>>>> discussion back at that level.
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <
> trkurc@gmail.com>
> >> > > >> wrote:
> >> > > >>>>>>>>> While I like gitflow, I can't say I like any of the
> plugins
> >> > that
> >> > > >> are
> >> > > >>>>>>> used.
> >> > > >>>>>>>>> I have worked on some other projects (unfortunately not
> open
> >> > > >> source)
> >> > > >>>>>>> that
> >> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a
> plugin.
> >> > > Nice
> >> > > >>>>> side
> >> > > >>>>>>>>> effect is that I believe this got me better at using git,
> and
> >> > > >>>>> generally
> >> > > >>>>>>> we
> >> > > >>>>>>>>> all got better at managing merge pain.
> >> > > >>>>>>>>>
> >> > > >>>>>>>>> On merge problems, I think the reason we're operating the
> way
> >> > we
> >> > > >> are
> >> > > >>>>>>> now is
> >> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a
> patch is
> >> > > "can
> >> > > >>> be
> >> > > >>>>>>>>> merged into master", and we have our friend Travis to make
> >> this
> >> > > >> even
> >> > > >>>>>>> easier
> >> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a
> bugfix
> >> is
> >> > > >>>>> "patch
> >> > > >>>>>>>>> needs to be able to apply onto the current release in
> >> progress,
> >> > > >>>>> master,
> >> > > >>>>>>> and
> >> > > >>>>>>>>> several other versions we're supporting, with possibly
> >> > > drastically
> >> > > >>>>>>>>> different code", well then things get interesting.
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>
> >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> >> > > >>>>>>> bimargulies@gmail.com>
> >> > > >>>>>>>>> wrote:
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>> The issue tracker
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >> > > >>>>>>>>>> might also prove useful in evaluating it.
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> >> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked
> >> great,
> >> > > >>>>> until
> >> > > >>>>>>> it
> >> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
> >> > > >> problems.
> >> > > >>>>> No
> >> > > >>>>>>>>>>> one seemed to be maintaining it.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> There's a new offering in this dept:
> >> > > >>>>>>>>>>>
> >> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> >> > adam@adamtaft.com
> >> > > >
> >> > > >>>>>>> wrote:
> >> > > >>>>>>>>>>>> One of the harder things with gitflow is using it in
> >> > > >> combination
> >> > > >>>>>>> with
> >> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are
> tracking
> >> > > >>>>> closely
> >> > > >>>>>>> with
> >> > > >>>>>>>>>> the
> >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't
> keep
> >> > the
> >> > > >> pom
> >> > > >>>>>>>>>> version
> >> > > >>>>>>>>>>>> updated with the git release names.
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> Because of the general importance of keeping releases
> and
> >> > tags
> >> > > >>>>>>>>>> synchronized
> >> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it needs
> to
> >> be
> >> > > >>>>>>> approached
> >> > > >>>>>>>>>>>> with tools that are available through maven rather than
> >> from
> >> > > >> git.
> >> > > >>>>>>> The
> >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly
> help
> >> > > deal
> >> > > >>>>> with
> >> > > >>>>>>>>>> this
> >> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven
> tool.
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow
> [1]
> >> > > >>>>> plugin,
> >> > > >>>>>>> which
> >> > > >>>>>>>>>>>> does a reasonable job of following the gitflow model
> for a
> >> > > >> maven
> >> > > >>>>>>>>>> project.
> >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it
> insists
> >> > > that
> >> > > >>>>> the
> >> > > >>>>>>>>>> master
> >> > > >>>>>>>>>>>> branch is strictly used for published release tags (as
> per
> >> > the
> >> > > >>>>>>> strict
> >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference
> to
> >> how
> >> > > >> some
> >> > > >>>>>>>>>> plugins
> >> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization
> issue.
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> >> > > >>>>> thadguidry@gmail.com
> >> > > >>>>>>>>
> >> > > >>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your
> >> Master
> >> > > >>>>> become
> >> > > >>>>>>>>>> primary
> >> > > >>>>>>>>>>>>> development of next release (with feature branches
> off of
> >> > > >> it)..
> >> > > >>>>>>> while
> >> > > >>>>>>>>>> you
> >> > > >>>>>>>>>>>>> continue to have release branches that can have hot
> fix
> >> > > >> branches
> >> > > >>>>>>> off of
> >> > > >>>>>>>>>>>>> them. (don't use Master as your release branch ! -
> bad
> >> > > >>>>> practice !
> >> > > >>>>>>> )
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for
> >> > everyone
> >> > > >> to
> >> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
> >> > understanding.
> >> > > >> Its
> >> > > >>>>>>> really
> >> > > >>>>>>>>>>>>> that easy.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow ...
> >> and
> >> > > >> tools
> >> > > >>>>>>> like
> >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have
> Git-flow
> >> > > either
> >> > > >>>>>>> built
> >> > > >>>>>>>>>> in or
> >> > > >>>>>>>>>>>>> plugin available now. If you want to live on the
> command
> >> > > >> line,
> >> > > >>>>>>> then
> >> > > >>>>>>>>>> that
> >> > > >>>>>>>>>>>>> is handled easily by the instructions in the above
> link.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> Thad
> >> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
>
Re: [DISCUSS] git branching model
Posted by Joe Witt <jo...@gmail.com>.
I too prefer option 1
On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <br...@jhu.edu> wrote:
> I agree with Tony on option 1. I think it makes sense for master to be
> the most "advanced" branch. New features will then always be applied to
> master, and optionally to other branches for older version support as
> applicable / desired.
>
> On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com> wrote:
>
>> I like option 1
>> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com> wrote:
>>
>> > Hello,
>> >
>> > With NiFi 0.6.0 officially released and our support strategy defined [1],
>> > I'd like to revisit and propose some options for supporting both a 1.x
>> > branch and 0.x branch concurrently. We need an official place where these
>> > efforts can be worked, contributed to, and collaborated with the
>> community.
>> > I've already created a 1.x branch as a temporary place for this codebase
>> to
>> > live until we agree to an approach.
>> >
>> > Either option I'm proposing will require PRs/contributions/patches to be
>> > applied to both branches as applicable. This means that the contributor
>> or
>> > the reviewer will need to be able to apply the commits in both places if
>> > it's necessary. For instance, framework code has already started
>> diverging
>> > from the current master so any framework change may not need to be
>> applied
>> > to both if the changeset is not applicable to the 1.x baseline.
>> >
>> > The only question at the moment is what master will refer to.
>> >
>> > 1) Create a branch for 0.x and allow master to become the 1.x baseline
>> > going forward. Future 0.x releases will be performed from the 0.x branch.
>> > 2) Continuing working on the 1.x branch as is. Allow master to continue
>> to
>> > servicing 0.x releases. Once a 1.x release is made, create the 0.x branch
>> > and then allow master to service 1.x releases.
>> >
>> > In short, when do we want master to point to the 1.x baseline? When
>> should
>> > we create a branch where 0.x releases will be made from. Regardless,
>> > contributions will need to be performed to both places as applicable.
>> >
>> > Thanks.
>> >
>> > Matt
>> >
>> > [1]
>> >
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> >
>> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <r....@gmail.com>
>> > wrote:
>> >
>> > > I guess it will depend how much change is expected on the maintenance
>> > > branches,
>> > > but if you want every change in the maintenance branch to go into the
>> > > main-line branch then there is little difference from a conflict point
>> of
>> > > view
>> > > between a series of cherry-picks and a merge.
>> > >
>> > > Either way, it is just another approach to consider. There’s more than
>> > one
>> > > way to do it, and I suspect there isn’t any solution that makes it
>> > trivial.
>> > >
>> > > Cheers,
>> > > Richard
>> > >
>> > >
>> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com> wrote:
>> > > >
>> > > > On board with Tony's points. I think the realities of merging in
>> > > practice
>> > > > when that "breaking point" of sorts occurs will make the complexity
>> and
>> > > > overhead quite difficult and maybe even more error prone than the
>> > cherry
>> > > > picking approach with some additional guidelines. When the codebase
>> > > > drastically changes, the merge conflicts could be quite severe and
>> > > without
>> > > > a good knowledge of each part of the codebase involved during that
>> > > process,
>> > > > a committer may introduce regressions.
>> > > >
>> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
>> > > >
>> > > >> the reason I like applying patches to both lines is that once code
>> > > begins
>> > > >> to diverge, cleanly merging into one codebase can be impossible.
>> > having
>> > > >> good practices for managing patches and where they apply is
>> paramount
>> > > for
>> > > >> success.
>> > > >>
>> > > >> I expect that divergence to happen with 1.x. I wanted to get in a
>> > battle
>> > > >> rhythm of sorts of managing multiple lines, even if the patches
>> COULD
>> > be
>> > > >> applied to both in the manner you described.
>> > > >>
>> > > >> Joe W and I did a wee bit of scrambling to ensure that tickets
>> marked
>> > > for
>> > > >> 0.5.1 had the right patches in the support branch, and some didn't,
>> > so I
>> > > >> think "lesson learned". I do like in the apache infrastructure that
>> if
>> > > >> commits have the appropriate ticket in their commit message, the
>> jira
>> > > will
>> > > >> have the list of commits and branches those commits were applies to.
>> > > >> However, I think we may need to revisit commit message "hygiene" if
>> > we
>> > > >> relied on this instead of more manual review.
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
>> r.p.miskin@gmail.com
>> > >
>> > > >> wrote:
>> > > >>
>> > > >>> Hi,
>> > > >>>
>> > > >>> On a couple of work projects we found that the approach of
>> > > cherry-picking
>> > > >>> commits can lead to an unnecessarily complicated history where the
>> > same
>> > > >>> piece of work appears as multiple separate commits on different
>> > > branches.
>> > > >>> This can then make it hard to be confident that a bug fix has been
>> > > >> applied
>> > > >>> to all relevant branches. We found that it works better to aim to
>> > > commit
>> > > >>> changes to the lowest applicable branch, and then regularly merge
>> > those
>> > > >>> branches to master. This approach is based on the git-flow model (
>> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
>> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
>> > > >>>
>> > > >>> Looking at the repo there are already a few commits that are
>> > duplicated
>> > > >> on
>> > > >>> master and 0.5.1. Using the model I suggest they’d only occur on
>> > 0.5.1,
>> > > >> and
>> > > >>> then that branch would get merged to master.
>> > > >>>
>> > > >>> Having the merge commits from the support branch to master makes it
>> > > >>> explicit in the git history that all bug fixes (and associated
>> tests)
>> > > >> have
>> > > >>> been pulled through to master.
>> > > >>>
>> > > >>> Cheers,
>> > > >>> Richard
>> > > >>>
>> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
>> > > >>>>
>> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see if you
>> > > agree:
>> > > >>>>
>> > > >>>> 1.) Commits merged to master today are destined for the next minor
>> > > >>> release,
>> > > >>>> currently 0.6.0, by default?
>> > > >>>>
>> > > >>>> By default, commits to master will be released in the next major
>> or
>> > > >> minor
>> > > >>>> release. No commits are included in incremental/patch releases by
>> > > >>> default.
>> > > >>>>
>> > > >>>>
>> > > >>>> 3.) How long will support/0.5.x be maintained?
>> > > >>>>
>> > > >>>> support/0.5.x will be maintained until the first of the following
>> > > >> events:
>> > > >>>> a.) 0.6.0 is released (next minor release in major release line)
>> > > >>>> b.) One year after 1.0.0 is released ("previous major release
>> lines
>> > up
>> > > >> to
>> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in that
>> line")
>> > > >>>>
>> > > >>>> But additional support might be available by special request.
>> > > >>>>
>> > > >>>>
>> > > >>>> 4.) Where is compatibility-breaking code destined for a future
>> major
>> > > >>>> release stored? Is it visible anywhere?
>> > > >>>>
>> > > >>>> I suppose Jira tickets targeting the next major release
>> > > >>> could/should/would
>> > > >>>> (do?) push branches. That seems weak in the face of a probable
>> > > >> stampede
>> > > >>>> towards the fire exit of a major release, but it's a start. I'm
>> not
>> > > >>> aware
>> > > >>>> of any great solutions here, certainly not for an open-source
>> > project.
>> > > >>>>
>> > > >>>>
>> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com>
>> > wrote:
>> > > >>>>
>> > > >>>>> James,
>> > > >>>>>
>> > > >>>>> These are great questions to frame and test the model. So let's
>> > > >>>>> attempt to address them agains the model.
>> > > >>>>>
>> > > >>>>> Here is the language for that model at this time:
>> > > >>>>>
>> > > >>>>> - 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'
>> > > >>>>>
>> > > >>>>> So with those above let's review 1 through 5 in turn.
>> > > >>>>>
>> > > >>>>> 1.) Commits merged to master today are destined for the next
>> minor
>> > > >>>>> release, currently 0.6.0, by default?
>> > > >>>>>
>> > > >>>>> Master is for whatever is the most leading edge release line
>> > working
>> > > >>>>> toward the next release. At the time that a minor release occurs
>> > > >>>>> against that release line then it branches off into a
>> support/x.y.*
>> > > >>>>> branch for any further efforts against it.
>> > > >>>>>
>> > > >>>>> 2.) Is master always open for merging new code, or are there
>> > > >>> restrictions
>> > > >>>>> before or after releases?
>> > > >>>>>
>> > > >>>>> I believe master would be always open for new code. From some
>> > point
>> > > >>>>> at which a release is considered feature complete then further
>> > > feature
>> > > >>>>> enhancements need to go on master as part of the next release
>> > effort.
>> > > >>>>>
>> > > >>>>> 3.) How long will support/0.5.x be maintained?
>> > > >>>>>
>> > > >>>>> The most recent minor release line of a major line will be
>> > supported
>> > > >>>>> for up to one year from whenever it was released where support is
>> > for
>> > > >>>>> bug fixes for security or data loss related items. Releases for
>> > > older
>> > > >>>>> minor lines should be considered on a case by case basis and if
>> > > >>>>> requested. Otherwise the basic premise is the train is moving
>> > > >>>>> forward.
>> > > >>>>>
>> > > >>>>> 4.) Where is compatibility-breaking code destined for a future
>> > major
>> > > >>>>> release stored? Is it visible anywhere?
>> > > >>>>>
>> > > >>>>> It must be visible. It should be placed into a branch until such
>> > > >>>>> time that it is ready to become the new master. That time would
>> be
>> > > >>>>> when the next release will be for that line. When I think about
>> > this
>> > > >>>>> against the stated model we could probably tweak the wording to
>> > > better
>> > > >>>>> articulate that. I think it was what was meant with 'when master
>> > has
>> > > >>>>> no releases we will backport...' but that is unclear.
>> > > >>>>>
>> > > >>>>> 5.) A critical data/security bug found after 1.0 would eligible
>> to
>> > be
>> > > >>>>> backported only to the last minor release in the 0.x line, or to
>> > all
>> > > >>> minor
>> > > >>>>> releases in the 0.x line?
>> > > >>>>>
>> > > >>>>> Only to the most recent minor release of any still supported
>> major
>> > > >>>>> line. However, the catch of 'case by case' determination for
>> older
>> > > >>>>> minor lines is still in play. Basically if someone requests it
>> and
>> > > >>>>> can get enough momentum for it then it should be no problem to
>> > > produce
>> > > >>>>> such a release.
>> > > >>>>>
>> > > >>>>> Thanks
>> > > >>>>> Joe
>> > > >>>>>
>> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com>
>> > > wrote:
>> > > >>>>>> I have some rhetorical questions for discussion of the branching
>> > > >> model:
>> > > >>>>>>
>> > > >>>>>> 1.) Commits merged to master today are destined for the next
>> minor
>> > > >>>>> release,
>> > > >>>>>> currently 0.6.0, by default?
>> > > >>>>>>
>> > > >>>>>> 2.) Is master always open for merging new code, or are there
>> > > >>> restrictions
>> > > >>>>>> before or after releases?
>> > > >>>>>>
>> > > >>>>>> 3.) How long will support/0.5.x be maintained?
>> > > >>>>>>
>> > > >>>>>> 4.) Where is compatibility-breaking code destined for a future
>> > major
>> > > >>>>>> release stored? Is it visible anywhere?
>> > > >>>>>>
>> > > >>>>>> 5.) A critical data/security bug found after 1.0 would eligible
>> to
>> > > be
>> > > >>>>>> backported only to the last minor release in the 0.x line, or to
>> > all
>> > > >>>>> minor
>> > > >>>>>> releases in the 0.x line?
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
>> > > >> wrote:
>> > > >>>>>>
>> > > >>>>>>> Given the discussion has stalled i'd like to turn it more
>> toward
>> > a
>> > > >>>>>>> proposal as we're at a point now where we need to start
>> executing
>> > > >> some
>> > > >>>>>>> of these approaches. We're actually already seeing it take
>> form
>> > in
>> > > >>>>>>> the support/0.5.x branch and the master branch (which is for
>> > 0.6.0
>> > > >> at
>> > > >>>>>>> this point).
>> > > >>>>>>>
>> > > >>>>>>> The proposal then for Git processes based on the other thread
>> [1]
>> > > >>>>>>> where we outline a support model:
>> > > >>>>>>>
>> > > >>>>>>> - 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
>> > > >>>>>>>
>> > > >>>>>>> [1]
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>> > > >>>>>>>
>> > > >>>>>>> Thanks
>> > > >>>>>>> Joe
>> > > >>>>>>>
>> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
>> > > >> wrote:
>> > > >>>>>>>> I don't want to kill this thread. It is good to discuss
>> > specific
>> > > >>>>>>>> tooling/procedures. But I do want to get some consensus
>> > > discussion
>> > > >>>>>>>> around Tony's original intent (as I read it). So kicked off a
>> > > >>>>>>>> discussion back at that level.
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
>> > > >> wrote:
>> > > >>>>>>>>> While I like gitflow, I can't say I like any of the plugins
>> > that
>> > > >> are
>> > > >>>>>>> used.
>> > > >>>>>>>>> I have worked on some other projects (unfortunately not open
>> > > >> source)
>> > > >>>>>>> that
>> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a plugin.
>> > > Nice
>> > > >>>>> side
>> > > >>>>>>>>> effect is that I believe this got me better at using git, and
>> > > >>>>> generally
>> > > >>>>>>> we
>> > > >>>>>>>>> all got better at managing merge pain.
>> > > >>>>>>>>>
>> > > >>>>>>>>> On merge problems, I think the reason we're operating the way
>> > we
>> > > >> are
>> > > >>>>>>> now is
>> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is
>> > > "can
>> > > >>> be
>> > > >>>>>>>>> merged into master", and we have our friend Travis to make
>> this
>> > > >> even
>> > > >>>>>>> easier
>> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix
>> is
>> > > >>>>> "patch
>> > > >>>>>>>>> needs to be able to apply onto the current release in
>> progress,
>> > > >>>>> master,
>> > > >>>>>>> and
>> > > >>>>>>>>> several other versions we're supporting, with possibly
>> > > drastically
>> > > >>>>>>>>> different code", well then things get interesting.
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>> > > >>>>>>> bimargulies@gmail.com>
>> > > >>>>>>>>> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>>> The issue tracker
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>> > > >>>>>>>>>> might also prove useful in evaluating it.
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>> > > >>>>>>>>>> <bi...@gmail.com> wrote:
>> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked
>> great,
>> > > >>>>> until
>> > > >>>>>>> it
>> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
>> > > >> problems.
>> > > >>>>> No
>> > > >>>>>>>>>>> one seemed to be maintaining it.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> There's a new offering in this dept:
>> > > >>>>>>>>>>>
>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
>> > adam@adamtaft.com
>> > > >
>> > > >>>>>>> wrote:
>> > > >>>>>>>>>>>> One of the harder things with gitflow is using it in
>> > > >> combination
>> > > >>>>>>> with
>> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking
>> > > >>>>> closely
>> > > >>>>>>> with
>> > > >>>>>>>>>> the
>> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep
>> > the
>> > > >> pom
>> > > >>>>>>>>>> version
>> > > >>>>>>>>>>>> updated with the git release names.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> Because of the general importance of keeping releases and
>> > tags
>> > > >>>>>>>>>> synchronized
>> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it needs to
>> be
>> > > >>>>>>> approached
>> > > >>>>>>>>>>>> with tools that are available through maven rather than
>> from
>> > > >> git.
>> > > >>>>>>> The
>> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help
>> > > deal
>> > > >>>>> with
>> > > >>>>>>>>>> this
>> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
>> > > >>>>> plugin,
>> > > >>>>>>> which
>> > > >>>>>>>>>>>> does a reasonable job of following the gitflow model for a
>> > > >> maven
>> > > >>>>>>>>>> project.
>> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists
>> > > that
>> > > >>>>> the
>> > > >>>>>>>>>> master
>> > > >>>>>>>>>>>> branch is strictly used for published release tags (as per
>> > the
>> > > >>>>>>> strict
>> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference to
>> how
>> > > >> some
>> > > >>>>>>>>>> plugins
>> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization issue.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
>> > > >>>>> thadguidry@gmail.com
>> > > >>>>>>>>
>> > > >>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your
>> Master
>> > > >>>>> become
>> > > >>>>>>>>>> primary
>> > > >>>>>>>>>>>>> development of next release (with feature branches off of
>> > > >> it)..
>> > > >>>>>>> while
>> > > >>>>>>>>>> you
>> > > >>>>>>>>>>>>> continue to have release branches that can have hot fix
>> > > >> branches
>> > > >>>>>>> off of
>> > > >>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad
>> > > >>>>> practice !
>> > > >>>>>>> )
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for
>> > everyone
>> > > >> to
>> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
>> > understanding.
>> > > >> Its
>> > > >>>>>>> really
>> > > >>>>>>>>>>>>> that easy.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow ...
>> and
>> > > >> tools
>> > > >>>>>>> like
>> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow
>> > > either
>> > > >>>>>>> built
>> > > >>>>>>>>>> in or
>> > > >>>>>>>>>>>>> plugin available now. If you want to live on the command
>> > > >> line,
>> > > >>>>>>> then
>> > > >>>>>>>>>> that
>> > > >>>>>>>>>>>>> is handled easily by the instructions in the above link.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Thad
>> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
Re: [DISCUSS] git branching model
Posted by Brandon DeVries <br...@jhu.edu>.
I agree with Tony on option 1. I think it makes sense for master to be
the most "advanced" branch. New features will then always be applied to
master, and optionally to other branches for older version support as
applicable / desired.
On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc <tr...@gmail.com> wrote:
> I like option 1
> On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com> wrote:
>
> > Hello,
> >
> > With NiFi 0.6.0 officially released and our support strategy defined [1],
> > I'd like to revisit and propose some options for supporting both a 1.x
> > branch and 0.x branch concurrently. We need an official place where these
> > efforts can be worked, contributed to, and collaborated with the
> community.
> > I've already created a 1.x branch as a temporary place for this codebase
> to
> > live until we agree to an approach.
> >
> > Either option I'm proposing will require PRs/contributions/patches to be
> > applied to both branches as applicable. This means that the contributor
> or
> > the reviewer will need to be able to apply the commits in both places if
> > it's necessary. For instance, framework code has already started
> diverging
> > from the current master so any framework change may not need to be
> applied
> > to both if the changeset is not applicable to the 1.x baseline.
> >
> > The only question at the moment is what master will refer to.
> >
> > 1) Create a branch for 0.x and allow master to become the 1.x baseline
> > going forward. Future 0.x releases will be performed from the 0.x branch.
> > 2) Continuing working on the 1.x branch as is. Allow master to continue
> to
> > servicing 0.x releases. Once a 1.x release is made, create the 0.x branch
> > and then allow master to service 1.x releases.
> >
> > In short, when do we want master to point to the 1.x baseline? When
> should
> > we create a branch where 0.x releases will be made from. Regardless,
> > contributions will need to be performed to both places as applicable.
> >
> > Thanks.
> >
> > Matt
> >
> > [1]
> >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >
> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <r....@gmail.com>
> > wrote:
> >
> > > I guess it will depend how much change is expected on the maintenance
> > > branches,
> > > but if you want every change in the maintenance branch to go into the
> > > main-line branch then there is little difference from a conflict point
> of
> > > view
> > > between a series of cherry-picks and a merge.
> > >
> > > Either way, it is just another approach to consider. There’s more than
> > one
> > > way to do it, and I suspect there isn’t any solution that makes it
> > trivial.
> > >
> > > Cheers,
> > > Richard
> > >
> > >
> > > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com> wrote:
> > > >
> > > > On board with Tony's points. I think the realities of merging in
> > > practice
> > > > when that "breaking point" of sorts occurs will make the complexity
> and
> > > > overhead quite difficult and maybe even more error prone than the
> > cherry
> > > > picking approach with some additional guidelines. When the codebase
> > > > drastically changes, the merge conflicts could be quite severe and
> > > without
> > > > a good knowledge of each part of the codebase involved during that
> > > process,
> > > > a committer may introduce regressions.
> > > >
> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
> > > >
> > > >> the reason I like applying patches to both lines is that once code
> > > begins
> > > >> to diverge, cleanly merging into one codebase can be impossible.
> > having
> > > >> good practices for managing patches and where they apply is
> paramount
> > > for
> > > >> success.
> > > >>
> > > >> I expect that divergence to happen with 1.x. I wanted to get in a
> > battle
> > > >> rhythm of sorts of managing multiple lines, even if the patches
> COULD
> > be
> > > >> applied to both in the manner you described.
> > > >>
> > > >> Joe W and I did a wee bit of scrambling to ensure that tickets
> marked
> > > for
> > > >> 0.5.1 had the right patches in the support branch, and some didn't,
> > so I
> > > >> think "lesson learned". I do like in the apache infrastructure that
> if
> > > >> commits have the appropriate ticket in their commit message, the
> jira
> > > will
> > > >> have the list of commits and branches those commits were applies to.
> > > >> However, I think we may need to revisit commit message "hygiene" if
> > we
> > > >> relied on this instead of more manual review.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <
> r.p.miskin@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> On a couple of work projects we found that the approach of
> > > cherry-picking
> > > >>> commits can lead to an unnecessarily complicated history where the
> > same
> > > >>> piece of work appears as multiple separate commits on different
> > > branches.
> > > >>> This can then make it hard to be confident that a bug fix has been
> > > >> applied
> > > >>> to all relevant branches. We found that it works better to aim to
> > > commit
> > > >>> changes to the lowest applicable branch, and then regularly merge
> > those
> > > >>> branches to master. This approach is based on the git-flow model (
> > > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> > > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> > > >>>
> > > >>> Looking at the repo there are already a few commits that are
> > duplicated
> > > >> on
> > > >>> master and 0.5.1. Using the model I suggest they’d only occur on
> > 0.5.1,
> > > >> and
> > > >>> then that branch would get merged to master.
> > > >>>
> > > >>> Having the merge commits from the support branch to master makes it
> > > >>> explicit in the git history that all bug fixes (and associated
> tests)
> > > >> have
> > > >>> been pulled through to master.
> > > >>>
> > > >>> Cheers,
> > > >>> Richard
> > > >>>
> > > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> > > >>>>
> > > >>>> Thanks, Joe, let me try rephrasing a few of those and see if you
> > > agree:
> > > >>>>
> > > >>>> 1.) Commits merged to master today are destined for the next minor
> > > >>> release,
> > > >>>> currently 0.6.0, by default?
> > > >>>>
> > > >>>> By default, commits to master will be released in the next major
> or
> > > >> minor
> > > >>>> release. No commits are included in incremental/patch releases by
> > > >>> default.
> > > >>>>
> > > >>>>
> > > >>>> 3.) How long will support/0.5.x be maintained?
> > > >>>>
> > > >>>> support/0.5.x will be maintained until the first of the following
> > > >> events:
> > > >>>> a.) 0.6.0 is released (next minor release in major release line)
> > > >>>> b.) One year after 1.0.0 is released ("previous major release
> lines
> > up
> > > >> to
> > > >>>> one year since the last minor release (0.4.y, 1.5.y) in that
> line")
> > > >>>>
> > > >>>> But additional support might be available by special request.
> > > >>>>
> > > >>>>
> > > >>>> 4.) Where is compatibility-breaking code destined for a future
> major
> > > >>>> release stored? Is it visible anywhere?
> > > >>>>
> > > >>>> I suppose Jira tickets targeting the next major release
> > > >>> could/should/would
> > > >>>> (do?) push branches. That seems weak in the face of a probable
> > > >> stampede
> > > >>>> towards the fire exit of a major release, but it's a start. I'm
> not
> > > >>> aware
> > > >>>> of any great solutions here, certainly not for an open-source
> > project.
> > > >>>>
> > > >>>>
> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com>
> > wrote:
> > > >>>>
> > > >>>>> James,
> > > >>>>>
> > > >>>>> These are great questions to frame and test the model. So let's
> > > >>>>> attempt to address them agains the model.
> > > >>>>>
> > > >>>>> Here is the language for that model at this time:
> > > >>>>>
> > > >>>>> - 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'
> > > >>>>>
> > > >>>>> So with those above let's review 1 through 5 in turn.
> > > >>>>>
> > > >>>>> 1.) Commits merged to master today are destined for the next
> minor
> > > >>>>> release, currently 0.6.0, by default?
> > > >>>>>
> > > >>>>> Master is for whatever is the most leading edge release line
> > working
> > > >>>>> toward the next release. At the time that a minor release occurs
> > > >>>>> against that release line then it branches off into a
> support/x.y.*
> > > >>>>> branch for any further efforts against it.
> > > >>>>>
> > > >>>>> 2.) Is master always open for merging new code, or are there
> > > >>> restrictions
> > > >>>>> before or after releases?
> > > >>>>>
> > > >>>>> I believe master would be always open for new code. From some
> > point
> > > >>>>> at which a release is considered feature complete then further
> > > feature
> > > >>>>> enhancements need to go on master as part of the next release
> > effort.
> > > >>>>>
> > > >>>>> 3.) How long will support/0.5.x be maintained?
> > > >>>>>
> > > >>>>> The most recent minor release line of a major line will be
> > supported
> > > >>>>> for up to one year from whenever it was released where support is
> > for
> > > >>>>> bug fixes for security or data loss related items. Releases for
> > > older
> > > >>>>> minor lines should be considered on a case by case basis and if
> > > >>>>> requested. Otherwise the basic premise is the train is moving
> > > >>>>> forward.
> > > >>>>>
> > > >>>>> 4.) Where is compatibility-breaking code destined for a future
> > major
> > > >>>>> release stored? Is it visible anywhere?
> > > >>>>>
> > > >>>>> It must be visible. It should be placed into a branch until such
> > > >>>>> time that it is ready to become the new master. That time would
> be
> > > >>>>> when the next release will be for that line. When I think about
> > this
> > > >>>>> against the stated model we could probably tweak the wording to
> > > better
> > > >>>>> articulate that. I think it was what was meant with 'when master
> > has
> > > >>>>> no releases we will backport...' but that is unclear.
> > > >>>>>
> > > >>>>> 5.) A critical data/security bug found after 1.0 would eligible
> to
> > be
> > > >>>>> backported only to the last minor release in the 0.x line, or to
> > all
> > > >>> minor
> > > >>>>> releases in the 0.x line?
> > > >>>>>
> > > >>>>> Only to the most recent minor release of any still supported
> major
> > > >>>>> line. However, the catch of 'case by case' determination for
> older
> > > >>>>> minor lines is still in play. Basically if someone requests it
> and
> > > >>>>> can get enough momentum for it then it should be no problem to
> > > produce
> > > >>>>> such a release.
> > > >>>>>
> > > >>>>> Thanks
> > > >>>>> Joe
> > > >>>>>
> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com>
> > > wrote:
> > > >>>>>> I have some rhetorical questions for discussion of the branching
> > > >> model:
> > > >>>>>>
> > > >>>>>> 1.) Commits merged to master today are destined for the next
> minor
> > > >>>>> release,
> > > >>>>>> currently 0.6.0, by default?
> > > >>>>>>
> > > >>>>>> 2.) Is master always open for merging new code, or are there
> > > >>> restrictions
> > > >>>>>> before or after releases?
> > > >>>>>>
> > > >>>>>> 3.) How long will support/0.5.x be maintained?
> > > >>>>>>
> > > >>>>>> 4.) Where is compatibility-breaking code destined for a future
> > major
> > > >>>>>> release stored? Is it visible anywhere?
> > > >>>>>>
> > > >>>>>> 5.) A critical data/security bug found after 1.0 would eligible
> to
> > > be
> > > >>>>>> backported only to the last minor release in the 0.x line, or to
> > all
> > > >>>>> minor
> > > >>>>>> releases in the 0.x line?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
> > > >> wrote:
> > > >>>>>>
> > > >>>>>>> Given the discussion has stalled i'd like to turn it more
> toward
> > a
> > > >>>>>>> proposal as we're at a point now where we need to start
> executing
> > > >> some
> > > >>>>>>> of these approaches. We're actually already seeing it take
> form
> > in
> > > >>>>>>> the support/0.5.x branch and the master branch (which is for
> > 0.6.0
> > > >> at
> > > >>>>>>> this point).
> > > >>>>>>>
> > > >>>>>>> The proposal then for Git processes based on the other thread
> [1]
> > > >>>>>>> where we outline a support model:
> > > >>>>>>>
> > > >>>>>>> - 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
> > > >>>>>>>
> > > >>>>>>> [1]
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > > >>>>>>>
> > > >>>>>>> Thanks
> > > >>>>>>> Joe
> > > >>>>>>>
> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
> > > >> wrote:
> > > >>>>>>>> I don't want to kill this thread. It is good to discuss
> > specific
> > > >>>>>>>> tooling/procedures. But I do want to get some consensus
> > > discussion
> > > >>>>>>>> around Tony's original intent (as I read it). So kicked off a
> > > >>>>>>>> discussion back at that level.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
> > > >> wrote:
> > > >>>>>>>>> While I like gitflow, I can't say I like any of the plugins
> > that
> > > >> are
> > > >>>>>>> used.
> > > >>>>>>>>> I have worked on some other projects (unfortunately not open
> > > >> source)
> > > >>>>>>> that
> > > >>>>>>>>> use a gitflow inspired workflow, without ever using a plugin.
> > > Nice
> > > >>>>> side
> > > >>>>>>>>> effect is that I believe this got me better at using git, and
> > > >>>>> generally
> > > >>>>>>> we
> > > >>>>>>>>> all got better at managing merge pain.
> > > >>>>>>>>>
> > > >>>>>>>>> On merge problems, I think the reason we're operating the way
> > we
> > > >> are
> > > >>>>>>> now is
> > > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is
> > > "can
> > > >>> be
> > > >>>>>>>>> merged into master", and we have our friend Travis to make
> this
> > > >> even
> > > >>>>>>> easier
> > > >>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix
> is
> > > >>>>> "patch
> > > >>>>>>>>> needs to be able to apply onto the current release in
> progress,
> > > >>>>> master,
> > > >>>>>>> and
> > > >>>>>>>>> several other versions we're supporting, with possibly
> > > drastically
> > > >>>>>>>>> different code", well then things get interesting.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> > > >>>>>>> bimargulies@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> The issue tracker
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > > >>>>>>>>>> might also prove useful in evaluating it.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> > > >>>>>>>>>> <bi...@gmail.com> wrote:
> > > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked
> great,
> > > >>>>> until
> > > >>>>>>> it
> > > >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
> > > >> problems.
> > > >>>>> No
> > > >>>>>>>>>>> one seemed to be maintaining it.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> There's a new offering in this dept:
> > > >>>>>>>>>>>
> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> > adam@adamtaft.com
> > > >
> > > >>>>>>> wrote:
> > > >>>>>>>>>>>> One of the harder things with gitflow is using it in
> > > >> combination
> > > >>>>>>> with
> > > >>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking
> > > >>>>> closely
> > > >>>>>>> with
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep
> > the
> > > >> pom
> > > >>>>>>>>>> version
> > > >>>>>>>>>>>> updated with the git release names.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Because of the general importance of keeping releases and
> > tags
> > > >>>>>>>>>> synchronized
> > > >>>>>>>>>>>> with the pom version, I think whatever we do, it needs to
> be
> > > >>>>>>> approached
> > > >>>>>>>>>>>> with tools that are available through maven rather than
> from
> > > >> git.
> > > >>>>>>> The
> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help
> > > deal
> > > >>>>> with
> > > >>>>>>>>>> this
> > > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
> > > >>>>> plugin,
> > > >>>>>>> which
> > > >>>>>>>>>>>> does a reasonable job of following the gitflow model for a
> > > >> maven
> > > >>>>>>>>>> project.
> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists
> > > that
> > > >>>>> the
> > > >>>>>>>>>> master
> > > >>>>>>>>>>>> branch is strictly used for published release tags (as per
> > the
> > > >>>>>>> strict
> > > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference to
> how
> > > >> some
> > > >>>>>>>>>> plugins
> > > >>>>>>>>>>>> are tackling the gitflow and maven synchronization issue.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> > > >>>>> thadguidry@gmail.com
> > > >>>>>>>>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your
> Master
> > > >>>>> become
> > > >>>>>>>>>> primary
> > > >>>>>>>>>>>>> development of next release (with feature branches off of
> > > >> it)..
> > > >>>>>>> while
> > > >>>>>>>>>> you
> > > >>>>>>>>>>>>> continue to have release branches that can have hot fix
> > > >> branches
> > > >>>>>>> off of
> > > >>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad
> > > >>>>> practice !
> > > >>>>>>> )
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for
> > everyone
> > > >> to
> > > >>>>>>>>>>>>> understand... just scroll it down to gain the
> > understanding.
> > > >> Its
> > > >>>>>>> really
> > > >>>>>>>>>>>>> that easy.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Most large projects have moved into using git-flow ...
> and
> > > >> tools
> > > >>>>>>> like
> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow
> > > either
> > > >>>>>>> built
> > > >>>>>>>>>> in or
> > > >>>>>>>>>>>>> plugin available now. If you want to live on the command
> > > >> line,
> > > >>>>>>> then
> > > >>>>>>>>>> that
> > > >>>>>>>>>>>>> is handled easily by the instructions in the above link.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thad
> > > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
I like option 1
On Mar 29, 2016 10:03 AM, "Matt Gilman" <ma...@gmail.com> wrote:
> Hello,
>
> With NiFi 0.6.0 officially released and our support strategy defined [1],
> I'd like to revisit and propose some options for supporting both a 1.x
> branch and 0.x branch concurrently. We need an official place where these
> efforts can be worked, contributed to, and collaborated with the community.
> I've already created a 1.x branch as a temporary place for this codebase to
> live until we agree to an approach.
>
> Either option I'm proposing will require PRs/contributions/patches to be
> applied to both branches as applicable. This means that the contributor or
> the reviewer will need to be able to apply the commits in both places if
> it's necessary. For instance, framework code has already started diverging
> from the current master so any framework change may not need to be applied
> to both if the changeset is not applicable to the 1.x baseline.
>
> The only question at the moment is what master will refer to.
>
> 1) Create a branch for 0.x and allow master to become the 1.x baseline
> going forward. Future 0.x releases will be performed from the 0.x branch.
> 2) Continuing working on the 1.x branch as is. Allow master to continue to
> servicing 0.x releases. Once a 1.x release is made, create the 0.x branch
> and then allow master to service 1.x releases.
>
> In short, when do we want master to point to the 1.x baseline? When should
> we create a branch where 0.x releases will be made from. Regardless,
> contributions will need to be performed to both places as applicable.
>
> Thanks.
>
> Matt
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>
> On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <r....@gmail.com>
> wrote:
>
> > I guess it will depend how much change is expected on the maintenance
> > branches,
> > but if you want every change in the maintenance branch to go into the
> > main-line branch then there is little difference from a conflict point of
> > view
> > between a series of cherry-picks and a merge.
> >
> > Either way, it is just another approach to consider. There’s more than
> one
> > way to do it, and I suspect there isn’t any solution that makes it
> trivial.
> >
> > Cheers,
> > Richard
> >
> >
> > > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com> wrote:
> > >
> > > On board with Tony's points. I think the realities of merging in
> > practice
> > > when that "breaking point" of sorts occurs will make the complexity and
> > > overhead quite difficult and maybe even more error prone than the
> cherry
> > > picking approach with some additional guidelines. When the codebase
> > > drastically changes, the merge conflicts could be quite severe and
> > without
> > > a good knowledge of each part of the codebase involved during that
> > process,
> > > a committer may introduce regressions.
> > >
> > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
> > >
> > >> the reason I like applying patches to both lines is that once code
> > begins
> > >> to diverge, cleanly merging into one codebase can be impossible.
> having
> > >> good practices for managing patches and where they apply is paramount
> > for
> > >> success.
> > >>
> > >> I expect that divergence to happen with 1.x. I wanted to get in a
> battle
> > >> rhythm of sorts of managing multiple lines, even if the patches COULD
> be
> > >> applied to both in the manner you described.
> > >>
> > >> Joe W and I did a wee bit of scrambling to ensure that tickets marked
> > for
> > >> 0.5.1 had the right patches in the support branch, and some didn't,
> so I
> > >> think "lesson learned". I do like in the apache infrastructure that if
> > >> commits have the appropriate ticket in their commit message, the jira
> > will
> > >> have the list of commits and branches those commits were applies to.
> > >> However, I think we may need to revisit commit message "hygiene" if
> we
> > >> relied on this instead of more manual review.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <r.p.miskin@gmail.com
> >
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> On a couple of work projects we found that the approach of
> > cherry-picking
> > >>> commits can lead to an unnecessarily complicated history where the
> same
> > >>> piece of work appears as multiple separate commits on different
> > branches.
> > >>> This can then make it hard to be confident that a bug fix has been
> > >> applied
> > >>> to all relevant branches. We found that it works better to aim to
> > commit
> > >>> changes to the lowest applicable branch, and then regularly merge
> those
> > >>> branches to master. This approach is based on the git-flow model (
> > >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> > >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> > >>>
> > >>> Looking at the repo there are already a few commits that are
> duplicated
> > >> on
> > >>> master and 0.5.1. Using the model I suggest they’d only occur on
> 0.5.1,
> > >> and
> > >>> then that branch would get merged to master.
> > >>>
> > >>> Having the merge commits from the support branch to master makes it
> > >>> explicit in the git history that all bug fixes (and associated tests)
> > >> have
> > >>> been pulled through to master.
> > >>>
> > >>> Cheers,
> > >>> Richard
> > >>>
> > >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> > >>>>
> > >>>> Thanks, Joe, let me try rephrasing a few of those and see if you
> > agree:
> > >>>>
> > >>>> 1.) Commits merged to master today are destined for the next minor
> > >>> release,
> > >>>> currently 0.6.0, by default?
> > >>>>
> > >>>> By default, commits to master will be released in the next major or
> > >> minor
> > >>>> release. No commits are included in incremental/patch releases by
> > >>> default.
> > >>>>
> > >>>>
> > >>>> 3.) How long will support/0.5.x be maintained?
> > >>>>
> > >>>> support/0.5.x will be maintained until the first of the following
> > >> events:
> > >>>> a.) 0.6.0 is released (next minor release in major release line)
> > >>>> b.) One year after 1.0.0 is released ("previous major release lines
> up
> > >> to
> > >>>> one year since the last minor release (0.4.y, 1.5.y) in that line")
> > >>>>
> > >>>> But additional support might be available by special request.
> > >>>>
> > >>>>
> > >>>> 4.) Where is compatibility-breaking code destined for a future major
> > >>>> release stored? Is it visible anywhere?
> > >>>>
> > >>>> I suppose Jira tickets targeting the next major release
> > >>> could/should/would
> > >>>> (do?) push branches. That seems weak in the face of a probable
> > >> stampede
> > >>>> towards the fire exit of a major release, but it's a start. I'm not
> > >>> aware
> > >>>> of any great solutions here, certainly not for an open-source
> project.
> > >>>>
> > >>>>
> > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > >>>>
> > >>>>> James,
> > >>>>>
> > >>>>> These are great questions to frame and test the model. So let's
> > >>>>> attempt to address them agains the model.
> > >>>>>
> > >>>>> Here is the language for that model at this time:
> > >>>>>
> > >>>>> - 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'
> > >>>>>
> > >>>>> So with those above let's review 1 through 5 in turn.
> > >>>>>
> > >>>>> 1.) Commits merged to master today are destined for the next minor
> > >>>>> release, currently 0.6.0, by default?
> > >>>>>
> > >>>>> Master is for whatever is the most leading edge release line
> working
> > >>>>> toward the next release. At the time that a minor release occurs
> > >>>>> against that release line then it branches off into a support/x.y.*
> > >>>>> branch for any further efforts against it.
> > >>>>>
> > >>>>> 2.) Is master always open for merging new code, or are there
> > >>> restrictions
> > >>>>> before or after releases?
> > >>>>>
> > >>>>> I believe master would be always open for new code. From some
> point
> > >>>>> at which a release is considered feature complete then further
> > feature
> > >>>>> enhancements need to go on master as part of the next release
> effort.
> > >>>>>
> > >>>>> 3.) How long will support/0.5.x be maintained?
> > >>>>>
> > >>>>> The most recent minor release line of a major line will be
> supported
> > >>>>> for up to one year from whenever it was released where support is
> for
> > >>>>> bug fixes for security or data loss related items. Releases for
> > older
> > >>>>> minor lines should be considered on a case by case basis and if
> > >>>>> requested. Otherwise the basic premise is the train is moving
> > >>>>> forward.
> > >>>>>
> > >>>>> 4.) Where is compatibility-breaking code destined for a future
> major
> > >>>>> release stored? Is it visible anywhere?
> > >>>>>
> > >>>>> It must be visible. It should be placed into a branch until such
> > >>>>> time that it is ready to become the new master. That time would be
> > >>>>> when the next release will be for that line. When I think about
> this
> > >>>>> against the stated model we could probably tweak the wording to
> > better
> > >>>>> articulate that. I think it was what was meant with 'when master
> has
> > >>>>> no releases we will backport...' but that is unclear.
> > >>>>>
> > >>>>> 5.) A critical data/security bug found after 1.0 would eligible to
> be
> > >>>>> backported only to the last minor release in the 0.x line, or to
> all
> > >>> minor
> > >>>>> releases in the 0.x line?
> > >>>>>
> > >>>>> Only to the most recent minor release of any still supported major
> > >>>>> line. However, the catch of 'case by case' determination for older
> > >>>>> minor lines is still in play. Basically if someone requests it and
> > >>>>> can get enough momentum for it then it should be no problem to
> > produce
> > >>>>> such a release.
> > >>>>>
> > >>>>> Thanks
> > >>>>> Joe
> > >>>>>
> > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com>
> > wrote:
> > >>>>>> I have some rhetorical questions for discussion of the branching
> > >> model:
> > >>>>>>
> > >>>>>> 1.) Commits merged to master today are destined for the next minor
> > >>>>> release,
> > >>>>>> currently 0.6.0, by default?
> > >>>>>>
> > >>>>>> 2.) Is master always open for merging new code, or are there
> > >>> restrictions
> > >>>>>> before or after releases?
> > >>>>>>
> > >>>>>> 3.) How long will support/0.5.x be maintained?
> > >>>>>>
> > >>>>>> 4.) Where is compatibility-breaking code destined for a future
> major
> > >>>>>> release stored? Is it visible anywhere?
> > >>>>>>
> > >>>>>> 5.) A critical data/security bug found after 1.0 would eligible to
> > be
> > >>>>>> backported only to the last minor release in the 0.x line, or to
> all
> > >>>>> minor
> > >>>>>> releases in the 0.x line?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
> > >> wrote:
> > >>>>>>
> > >>>>>>> Given the discussion has stalled i'd like to turn it more toward
> a
> > >>>>>>> proposal as we're at a point now where we need to start executing
> > >> some
> > >>>>>>> of these approaches. We're actually already seeing it take form
> in
> > >>>>>>> the support/0.5.x branch and the master branch (which is for
> 0.6.0
> > >> at
> > >>>>>>> this point).
> > >>>>>>>
> > >>>>>>> The proposal then for Git processes based on the other thread [1]
> > >>>>>>> where we outline a support model:
> > >>>>>>>
> > >>>>>>> - 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
> > >>>>>>>
> > >>>>>>> [1]
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> Joe
> > >>>>>>>
> > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
> > >> wrote:
> > >>>>>>>> I don't want to kill this thread. It is good to discuss
> specific
> > >>>>>>>> tooling/procedures. But I do want to get some consensus
> > discussion
> > >>>>>>>> around Tony's original intent (as I read it). So kicked off a
> > >>>>>>>> discussion back at that level.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
> > >> wrote:
> > >>>>>>>>> While I like gitflow, I can't say I like any of the plugins
> that
> > >> are
> > >>>>>>> used.
> > >>>>>>>>> I have worked on some other projects (unfortunately not open
> > >> source)
> > >>>>>>> that
> > >>>>>>>>> use a gitflow inspired workflow, without ever using a plugin.
> > Nice
> > >>>>> side
> > >>>>>>>>> effect is that I believe this got me better at using git, and
> > >>>>> generally
> > >>>>>>> we
> > >>>>>>>>> all got better at managing merge pain.
> > >>>>>>>>>
> > >>>>>>>>> On merge problems, I think the reason we're operating the way
> we
> > >> are
> > >>>>>>> now is
> > >>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is
> > "can
> > >>> be
> > >>>>>>>>> merged into master", and we have our friend Travis to make this
> > >> even
> > >>>>>>> easier
> > >>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix is
> > >>>>> "patch
> > >>>>>>>>> needs to be able to apply onto the current release in progress,
> > >>>>> master,
> > >>>>>>> and
> > >>>>>>>>> several other versions we're supporting, with possibly
> > drastically
> > >>>>>>>>> different code", well then things get interesting.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> > >>>>>>> bimargulies@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> The issue tracker
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > >>>>>>>>>> might also prove useful in evaluating it.
> > >>>>>>>>>>
> > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> > >>>>>>>>>> <bi...@gmail.com> wrote:
> > >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
> > >>>>> until
> > >>>>>>> it
> > >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
> > >> problems.
> > >>>>> No
> > >>>>>>>>>>> one seemed to be maintaining it.
> > >>>>>>>>>>>
> > >>>>>>>>>>> There's a new offering in this dept:
> > >>>>>>>>>>>
> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <
> adam@adamtaft.com
> > >
> > >>>>>>> wrote:
> > >>>>>>>>>>>> One of the harder things with gitflow is using it in
> > >> combination
> > >>>>>>> with
> > >>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking
> > >>>>> closely
> > >>>>>>> with
> > >>>>>>>>>> the
> > >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep
> the
> > >> pom
> > >>>>>>>>>> version
> > >>>>>>>>>>>> updated with the git release names.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Because of the general importance of keeping releases and
> tags
> > >>>>>>>>>> synchronized
> > >>>>>>>>>>>> with the pom version, I think whatever we do, it needs to be
> > >>>>>>> approached
> > >>>>>>>>>>>> with tools that are available through maven rather than from
> > >> git.
> > >>>>>>> The
> > >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help
> > deal
> > >>>>> with
> > >>>>>>>>>> this
> > >>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
> > >>>>> plugin,
> > >>>>>>> which
> > >>>>>>>>>>>> does a reasonable job of following the gitflow model for a
> > >> maven
> > >>>>>>>>>> project.
> > >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists
> > that
> > >>>>> the
> > >>>>>>>>>> master
> > >>>>>>>>>>>> branch is strictly used for published release tags (as per
> the
> > >>>>>>> strict
> > >>>>>>>>>>>> gitflow workflow). I just mention this, in reference to how
> > >> some
> > >>>>>>>>>> plugins
> > >>>>>>>>>>>> are tackling the gitflow and maven synchronization issue.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> > >>>>> thadguidry@gmail.com
> > >>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
> > >>>>> become
> > >>>>>>>>>> primary
> > >>>>>>>>>>>>> development of next release (with feature branches off of
> > >> it)..
> > >>>>>>> while
> > >>>>>>>>>> you
> > >>>>>>>>>>>>> continue to have release branches that can have hot fix
> > >> branches
> > >>>>>>> off of
> > >>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad
> > >>>>> practice !
> > >>>>>>> )
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for
> everyone
> > >> to
> > >>>>>>>>>>>>> understand... just scroll it down to gain the
> understanding.
> > >> Its
> > >>>>>>> really
> > >>>>>>>>>>>>> that easy.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Most large projects have moved into using git-flow ... and
> > >> tools
> > >>>>>>> like
> > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow
> > either
> > >>>>>>> built
> > >>>>>>>>>> in or
> > >>>>>>>>>>>>> plugin available now. If you want to live on the command
> > >> line,
> > >>>>>>> then
> > >>>>>>>>>> that
> > >>>>>>>>>>>>> is handled easily by the instructions in the above link.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thad
> > >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
Hello,
With NiFi 0.6.0 officially released and our support strategy defined [1],
I'd like to revisit and propose some options for supporting both a 1.x
branch and 0.x branch concurrently. We need an official place where these
efforts can be worked, contributed to, and collaborated with the community.
I've already created a 1.x branch as a temporary place for this codebase to
live until we agree to an approach.
Either option I'm proposing will require PRs/contributions/patches to be
applied to both branches as applicable. This means that the contributor or
the reviewer will need to be able to apply the commits in both places if
it's necessary. For instance, framework code has already started diverging
from the current master so any framework change may not need to be applied
to both if the changeset is not applicable to the 1.x baseline.
The only question at the moment is what master will refer to.
1) Create a branch for 0.x and allow master to become the 1.x baseline
going forward. Future 0.x releases will be performed from the 0.x branch.
2) Continuing working on the 1.x branch as is. Allow master to continue to
servicing 0.x releases. Once a 1.x release is made, create the 0.x branch
and then allow master to service 1.x releases.
In short, when do we want master to point to the 1.x baseline? When should
we create a branch where 0.x releases will be made from. Regardless,
contributions will need to be performed to both places as applicable.
Thanks.
Matt
[1]
http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin <r....@gmail.com>
wrote:
> I guess it will depend how much change is expected on the maintenance
> branches,
> but if you want every change in the maintenance branch to go into the
> main-line branch then there is little difference from a conflict point of
> view
> between a series of cherry-picks and a merge.
>
> Either way, it is just another approach to consider. There’s more than one
> way to do it, and I suspect there isn’t any solution that makes it trivial.
>
> Cheers,
> Richard
>
>
> > On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com> wrote:
> >
> > On board with Tony's points. I think the realities of merging in
> practice
> > when that "breaking point" of sorts occurs will make the complexity and
> > overhead quite difficult and maybe even more error prone than the cherry
> > picking approach with some additional guidelines. When the codebase
> > drastically changes, the merge conflicts could be quite severe and
> without
> > a good knowledge of each part of the codebase involved during that
> process,
> > a committer may introduce regressions.
> >
> > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
> >
> >> the reason I like applying patches to both lines is that once code
> begins
> >> to diverge, cleanly merging into one codebase can be impossible. having
> >> good practices for managing patches and where they apply is paramount
> for
> >> success.
> >>
> >> I expect that divergence to happen with 1.x. I wanted to get in a battle
> >> rhythm of sorts of managing multiple lines, even if the patches COULD be
> >> applied to both in the manner you described.
> >>
> >> Joe W and I did a wee bit of scrambling to ensure that tickets marked
> for
> >> 0.5.1 had the right patches in the support branch, and some didn't, so I
> >> think "lesson learned". I do like in the apache infrastructure that if
> >> commits have the appropriate ticket in their commit message, the jira
> will
> >> have the list of commits and branches those commits were applies to.
> >> However, I think we may need to revisit commit message "hygiene" if we
> >> relied on this instead of more manual review.
> >>
> >>
> >>
> >>
> >>
> >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <r....@gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On a couple of work projects we found that the approach of
> cherry-picking
> >>> commits can lead to an unnecessarily complicated history where the same
> >>> piece of work appears as multiple separate commits on different
> branches.
> >>> This can then make it hard to be confident that a bug fix has been
> >> applied
> >>> to all relevant branches. We found that it works better to aim to
> commit
> >>> changes to the lowest applicable branch, and then regularly merge those
> >>> branches to master. This approach is based on the git-flow model (
> >>> http://nvie.com/posts/a-successful-git-branching-model/ <
> >>> http://nvie.com/posts/a-successful-git-branching-model/>).
> >>>
> >>> Looking at the repo there are already a few commits that are duplicated
> >> on
> >>> master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1,
> >> and
> >>> then that branch would get merged to master.
> >>>
> >>> Having the merge commits from the support branch to master makes it
> >>> explicit in the git history that all bug fixes (and associated tests)
> >> have
> >>> been pulled through to master.
> >>>
> >>> Cheers,
> >>> Richard
> >>>
> >>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> >>>>
> >>>> Thanks, Joe, let me try rephrasing a few of those and see if you
> agree:
> >>>>
> >>>> 1.) Commits merged to master today are destined for the next minor
> >>> release,
> >>>> currently 0.6.0, by default?
> >>>>
> >>>> By default, commits to master will be released in the next major or
> >> minor
> >>>> release. No commits are included in incremental/patch releases by
> >>> default.
> >>>>
> >>>>
> >>>> 3.) How long will support/0.5.x be maintained?
> >>>>
> >>>> support/0.5.x will be maintained until the first of the following
> >> events:
> >>>> a.) 0.6.0 is released (next minor release in major release line)
> >>>> b.) One year after 1.0.0 is released ("previous major release lines up
> >> to
> >>>> one year since the last minor release (0.4.y, 1.5.y) in that line")
> >>>>
> >>>> But additional support might be available by special request.
> >>>>
> >>>>
> >>>> 4.) Where is compatibility-breaking code destined for a future major
> >>>> release stored? Is it visible anywhere?
> >>>>
> >>>> I suppose Jira tickets targeting the next major release
> >>> could/should/would
> >>>> (do?) push branches. That seems weak in the face of a probable
> >> stampede
> >>>> towards the fire exit of a major release, but it's a start. I'm not
> >>> aware
> >>>> of any great solutions here, certainly not for an open-source project.
> >>>>
> >>>>
> >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
> >>>>
> >>>>> James,
> >>>>>
> >>>>> These are great questions to frame and test the model. So let's
> >>>>> attempt to address them agains the model.
> >>>>>
> >>>>> Here is the language for that model at this time:
> >>>>>
> >>>>> - 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'
> >>>>>
> >>>>> So with those above let's review 1 through 5 in turn.
> >>>>>
> >>>>> 1.) Commits merged to master today are destined for the next minor
> >>>>> release, currently 0.6.0, by default?
> >>>>>
> >>>>> Master is for whatever is the most leading edge release line working
> >>>>> toward the next release. At the time that a minor release occurs
> >>>>> against that release line then it branches off into a support/x.y.*
> >>>>> branch for any further efforts against it.
> >>>>>
> >>>>> 2.) Is master always open for merging new code, or are there
> >>> restrictions
> >>>>> before or after releases?
> >>>>>
> >>>>> I believe master would be always open for new code. From some point
> >>>>> at which a release is considered feature complete then further
> feature
> >>>>> enhancements need to go on master as part of the next release effort.
> >>>>>
> >>>>> 3.) How long will support/0.5.x be maintained?
> >>>>>
> >>>>> The most recent minor release line of a major line will be supported
> >>>>> for up to one year from whenever it was released where support is for
> >>>>> bug fixes for security or data loss related items. Releases for
> older
> >>>>> minor lines should be considered on a case by case basis and if
> >>>>> requested. Otherwise the basic premise is the train is moving
> >>>>> forward.
> >>>>>
> >>>>> 4.) Where is compatibility-breaking code destined for a future major
> >>>>> release stored? Is it visible anywhere?
> >>>>>
> >>>>> It must be visible. It should be placed into a branch until such
> >>>>> time that it is ready to become the new master. That time would be
> >>>>> when the next release will be for that line. When I think about this
> >>>>> against the stated model we could probably tweak the wording to
> better
> >>>>> articulate that. I think it was what was meant with 'when master has
> >>>>> no releases we will backport...' but that is unclear.
> >>>>>
> >>>>> 5.) A critical data/security bug found after 1.0 would eligible to be
> >>>>> backported only to the last minor release in the 0.x line, or to all
> >>> minor
> >>>>> releases in the 0.x line?
> >>>>>
> >>>>> Only to the most recent minor release of any still supported major
> >>>>> line. However, the catch of 'case by case' determination for older
> >>>>> minor lines is still in play. Basically if someone requests it and
> >>>>> can get enough momentum for it then it should be no problem to
> produce
> >>>>> such a release.
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com>
> wrote:
> >>>>>> I have some rhetorical questions for discussion of the branching
> >> model:
> >>>>>>
> >>>>>> 1.) Commits merged to master today are destined for the next minor
> >>>>> release,
> >>>>>> currently 0.6.0, by default?
> >>>>>>
> >>>>>> 2.) Is master always open for merging new code, or are there
> >>> restrictions
> >>>>>> before or after releases?
> >>>>>>
> >>>>>> 3.) How long will support/0.5.x be maintained?
> >>>>>>
> >>>>>> 4.) Where is compatibility-breaking code destined for a future major
> >>>>>> release stored? Is it visible anywhere?
> >>>>>>
> >>>>>> 5.) A critical data/security bug found after 1.0 would eligible to
> be
> >>>>>> backported only to the last minor release in the 0.x line, or to all
> >>>>> minor
> >>>>>> releases in the 0.x line?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>>> Given the discussion has stalled i'd like to turn it more toward a
> >>>>>>> proposal as we're at a point now where we need to start executing
> >> some
> >>>>>>> of these approaches. We're actually already seeing it take form in
> >>>>>>> the support/0.5.x branch and the master branch (which is for 0.6.0
> >> at
> >>>>>>> this point).
> >>>>>>>
> >>>>>>> The proposal then for Git processes based on the other thread [1]
> >>>>>>> where we outline a support model:
> >>>>>>>
> >>>>>>> - 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
> >>>>>>>
> >>>>>>> [1]
> >>>>>>>
> >>>>>
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
> >> wrote:
> >>>>>>>> I don't want to kill this thread. It is good to discuss specific
> >>>>>>>> tooling/procedures. But I do want to get some consensus
> discussion
> >>>>>>>> around Tony's original intent (as I read it). So kicked off a
> >>>>>>>> discussion back at that level.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
> >> wrote:
> >>>>>>>>> While I like gitflow, I can't say I like any of the plugins that
> >> are
> >>>>>>> used.
> >>>>>>>>> I have worked on some other projects (unfortunately not open
> >> source)
> >>>>>>> that
> >>>>>>>>> use a gitflow inspired workflow, without ever using a plugin.
> Nice
> >>>>> side
> >>>>>>>>> effect is that I believe this got me better at using git, and
> >>>>> generally
> >>>>>>> we
> >>>>>>>>> all got better at managing merge pain.
> >>>>>>>>>
> >>>>>>>>> On merge problems, I think the reason we're operating the way we
> >> are
> >>>>>>> now is
> >>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is
> "can
> >>> be
> >>>>>>>>> merged into master", and we have our friend Travis to make this
> >> even
> >>>>>>> easier
> >>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix is
> >>>>> "patch
> >>>>>>>>> needs to be able to apply onto the current release in progress,
> >>>>> master,
> >>>>>>> and
> >>>>>>>>> several other versions we're supporting, with possibly
> drastically
> >>>>>>>>> different code", well then things get interesting.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> >>>>>>> bimargulies@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> The issue tracker
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >>>>>>>>>> might also prove useful in evaluating it.
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> >>>>>>>>>> <bi...@gmail.com> wrote:
> >>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
> >>>>> until
> >>>>>>> it
> >>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
> >> problems.
> >>>>> No
> >>>>>>>>>>> one seemed to be maintaining it.
> >>>>>>>>>>>
> >>>>>>>>>>> There's a new offering in this dept:
> >>>>>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <adam@adamtaft.com
> >
> >>>>>>> wrote:
> >>>>>>>>>>>> One of the harder things with gitflow is using it in
> >> combination
> >>>>>>> with
> >>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking
> >>>>> closely
> >>>>>>> with
> >>>>>>>>>> the
> >>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the
> >> pom
> >>>>>>>>>> version
> >>>>>>>>>>>> updated with the git release names.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because of the general importance of keeping releases and tags
> >>>>>>>>>> synchronized
> >>>>>>>>>>>> with the pom version, I think whatever we do, it needs to be
> >>>>>>> approached
> >>>>>>>>>>>> with tools that are available through maven rather than from
> >> git.
> >>>>>>> The
> >>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help
> deal
> >>>>> with
> >>>>>>>>>> this
> >>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
> >>>>> plugin,
> >>>>>>> which
> >>>>>>>>>>>> does a reasonable job of following the gitflow model for a
> >> maven
> >>>>>>>>>> project.
> >>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists
> that
> >>>>> the
> >>>>>>>>>> master
> >>>>>>>>>>>> branch is strictly used for published release tags (as per the
> >>>>>>> strict
> >>>>>>>>>>>> gitflow workflow). I just mention this, in reference to how
> >> some
> >>>>>>>>>> plugins
> >>>>>>>>>>>> are tackling the gitflow and maven synchronization issue.
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> >>>>> thadguidry@gmail.com
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
> >>>>> become
> >>>>>>>>>> primary
> >>>>>>>>>>>>> development of next release (with feature branches off of
> >> it)..
> >>>>>>> while
> >>>>>>>>>> you
> >>>>>>>>>>>>> continue to have release branches that can have hot fix
> >> branches
> >>>>>>> off of
> >>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad
> >>>>> practice !
> >>>>>>> )
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone
> >> to
> >>>>>>>>>>>>> understand... just scroll it down to gain the understanding.
> >> Its
> >>>>>>> really
> >>>>>>>>>>>>> that easy.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Most large projects have moved into using git-flow ... and
> >> tools
> >>>>>>> like
> >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow
> either
> >>>>>>> built
> >>>>>>>>>> in or
> >>>>>>>>>>>>> plugin available now. If you want to live on the command
> >> line,
> >>>>>>> then
> >>>>>>>>>> that
> >>>>>>>>>>>>> is handled easily by the instructions in the above link.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thad
> >>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: [DISCUSS] git branching model
Posted by Richard Miskin <r....@gmail.com>.
I guess it will depend how much change is expected on the maintenance branches,
but if you want every change in the maintenance branch to go into the
main-line branch then there is little difference from a conflict point of view
between a series of cherry-picks and a merge.
Either way, it is just another approach to consider. There’s more than one
way to do it, and I suspect there isn’t any solution that makes it trivial.
Cheers,
Richard
> On 27 Feb 2016, at 14:43, Aldrin Piri <al...@gmail.com> wrote:
>
> On board with Tony's points. I think the realities of merging in practice
> when that "breaking point" of sorts occurs will make the complexity and
> overhead quite difficult and maybe even more error prone than the cherry
> picking approach with some additional guidelines. When the codebase
> drastically changes, the merge conflicts could be quite severe and without
> a good knowledge of each part of the codebase involved during that process,
> a committer may introduce regressions.
>
> On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
>
>> the reason I like applying patches to both lines is that once code begins
>> to diverge, cleanly merging into one codebase can be impossible. having
>> good practices for managing patches and where they apply is paramount for
>> success.
>>
>> I expect that divergence to happen with 1.x. I wanted to get in a battle
>> rhythm of sorts of managing multiple lines, even if the patches COULD be
>> applied to both in the manner you described.
>>
>> Joe W and I did a wee bit of scrambling to ensure that tickets marked for
>> 0.5.1 had the right patches in the support branch, and some didn't, so I
>> think "lesson learned". I do like in the apache infrastructure that if
>> commits have the appropriate ticket in their commit message, the jira will
>> have the list of commits and branches those commits were applies to.
>> However, I think we may need to revisit commit message "hygiene" if we
>> relied on this instead of more manual review.
>>
>>
>>
>>
>>
>> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <r....@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On a couple of work projects we found that the approach of cherry-picking
>>> commits can lead to an unnecessarily complicated history where the same
>>> piece of work appears as multiple separate commits on different branches.
>>> This can then make it hard to be confident that a bug fix has been
>> applied
>>> to all relevant branches. We found that it works better to aim to commit
>>> changes to the lowest applicable branch, and then regularly merge those
>>> branches to master. This approach is based on the git-flow model (
>>> http://nvie.com/posts/a-successful-git-branching-model/ <
>>> http://nvie.com/posts/a-successful-git-branching-model/>).
>>>
>>> Looking at the repo there are already a few commits that are duplicated
>> on
>>> master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1,
>> and
>>> then that branch would get merged to master.
>>>
>>> Having the merge commits from the support branch to master makes it
>>> explicit in the git history that all bug fixes (and associated tests)
>> have
>>> been pulled through to master.
>>>
>>> Cheers,
>>> Richard
>>>
>>>> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
>>>>
>>>> Thanks, Joe, let me try rephrasing a few of those and see if you agree:
>>>>
>>>> 1.) Commits merged to master today are destined for the next minor
>>> release,
>>>> currently 0.6.0, by default?
>>>>
>>>> By default, commits to master will be released in the next major or
>> minor
>>>> release. No commits are included in incremental/patch releases by
>>> default.
>>>>
>>>>
>>>> 3.) How long will support/0.5.x be maintained?
>>>>
>>>> support/0.5.x will be maintained until the first of the following
>> events:
>>>> a.) 0.6.0 is released (next minor release in major release line)
>>>> b.) One year after 1.0.0 is released ("previous major release lines up
>> to
>>>> one year since the last minor release (0.4.y, 1.5.y) in that line")
>>>>
>>>> But additional support might be available by special request.
>>>>
>>>>
>>>> 4.) Where is compatibility-breaking code destined for a future major
>>>> release stored? Is it visible anywhere?
>>>>
>>>> I suppose Jira tickets targeting the next major release
>>> could/should/would
>>>> (do?) push branches. That seems weak in the face of a probable
>> stampede
>>>> towards the fire exit of a major release, but it's a start. I'm not
>>> aware
>>>> of any great solutions here, certainly not for an open-source project.
>>>>
>>>>
>>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>>> James,
>>>>>
>>>>> These are great questions to frame and test the model. So let's
>>>>> attempt to address them agains the model.
>>>>>
>>>>> Here is the language for that model at this time:
>>>>>
>>>>> - 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'
>>>>>
>>>>> So with those above let's review 1 through 5 in turn.
>>>>>
>>>>> 1.) Commits merged to master today are destined for the next minor
>>>>> release, currently 0.6.0, by default?
>>>>>
>>>>> Master is for whatever is the most leading edge release line working
>>>>> toward the next release. At the time that a minor release occurs
>>>>> against that release line then it branches off into a support/x.y.*
>>>>> branch for any further efforts against it.
>>>>>
>>>>> 2.) Is master always open for merging new code, or are there
>>> restrictions
>>>>> before or after releases?
>>>>>
>>>>> I believe master would be always open for new code. From some point
>>>>> at which a release is considered feature complete then further feature
>>>>> enhancements need to go on master as part of the next release effort.
>>>>>
>>>>> 3.) How long will support/0.5.x be maintained?
>>>>>
>>>>> The most recent minor release line of a major line will be supported
>>>>> for up to one year from whenever it was released where support is for
>>>>> bug fixes for security or data loss related items. Releases for older
>>>>> minor lines should be considered on a case by case basis and if
>>>>> requested. Otherwise the basic premise is the train is moving
>>>>> forward.
>>>>>
>>>>> 4.) Where is compatibility-breaking code destined for a future major
>>>>> release stored? Is it visible anywhere?
>>>>>
>>>>> It must be visible. It should be placed into a branch until such
>>>>> time that it is ready to become the new master. That time would be
>>>>> when the next release will be for that line. When I think about this
>>>>> against the stated model we could probably tweak the wording to better
>>>>> articulate that. I think it was what was meant with 'when master has
>>>>> no releases we will backport...' but that is unclear.
>>>>>
>>>>> 5.) A critical data/security bug found after 1.0 would eligible to be
>>>>> backported only to the last minor release in the 0.x line, or to all
>>> minor
>>>>> releases in the 0.x line?
>>>>>
>>>>> Only to the most recent minor release of any still supported major
>>>>> line. However, the catch of 'case by case' determination for older
>>>>> minor lines is still in play. Basically if someone requests it and
>>>>> can get enough momentum for it then it should be no problem to produce
>>>>> such a release.
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
>>>>>> I have some rhetorical questions for discussion of the branching
>> model:
>>>>>>
>>>>>> 1.) Commits merged to master today are destined for the next minor
>>>>> release,
>>>>>> currently 0.6.0, by default?
>>>>>>
>>>>>> 2.) Is master always open for merging new code, or are there
>>> restrictions
>>>>>> before or after releases?
>>>>>>
>>>>>> 3.) How long will support/0.5.x be maintained?
>>>>>>
>>>>>> 4.) Where is compatibility-breaking code destined for a future major
>>>>>> release stored? Is it visible anywhere?
>>>>>>
>>>>>> 5.) A critical data/security bug found after 1.0 would eligible to be
>>>>>> backported only to the last minor release in the 0.x line, or to all
>>>>> minor
>>>>>> releases in the 0.x line?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
>> wrote:
>>>>>>
>>>>>>> Given the discussion has stalled i'd like to turn it more toward a
>>>>>>> proposal as we're at a point now where we need to start executing
>> some
>>>>>>> of these approaches. We're actually already seeing it take form in
>>>>>>> the support/0.5.x branch and the master branch (which is for 0.6.0
>> at
>>>>>>> this point).
>>>>>>>
>>>>>>> The proposal then for Git processes based on the other thread [1]
>>>>>>> where we outline a support model:
>>>>>>>
>>>>>>> - 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
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>
>>>
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
>> wrote:
>>>>>>>> I don't want to kill this thread. It is good to discuss specific
>>>>>>>> tooling/procedures. But I do want to get some consensus discussion
>>>>>>>> around Tony's original intent (as I read it). So kicked off a
>>>>>>>> discussion back at that level.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
>> wrote:
>>>>>>>>> While I like gitflow, I can't say I like any of the plugins that
>> are
>>>>>>> used.
>>>>>>>>> I have worked on some other projects (unfortunately not open
>> source)
>>>>>>> that
>>>>>>>>> use a gitflow inspired workflow, without ever using a plugin. Nice
>>>>> side
>>>>>>>>> effect is that I believe this got me better at using git, and
>>>>> generally
>>>>>>> we
>>>>>>>>> all got better at managing merge pain.
>>>>>>>>>
>>>>>>>>> On merge problems, I think the reason we're operating the way we
>> are
>>>>>>> now is
>>>>>>>>> to avoid merge mayhem. I think the initial bar for a patch is "can
>>> be
>>>>>>>>> merged into master", and we have our friend Travis to make this
>> even
>>>>>>> easier
>>>>>>>>> to know upfront. This greatly simplifies things. If a bugfix is
>>>>> "patch
>>>>>>>>> needs to be able to apply onto the current release in progress,
>>>>> master,
>>>>>>> and
>>>>>>>>> several other versions we're supporting, with possibly drastically
>>>>>>>>> different code", well then things get interesting.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>>>>>>> bimargulies@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> The issue tracker
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>>>>>>>>>> might also prove useful in evaluating it.
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>>>>>>>>>> <bi...@gmail.com> wrote:
>>>>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
>>>>> until
>>>>>>> it
>>>>>>>>>>> didn't. It would get into terrible, inexplicable, merge
>> problems.
>>>>> No
>>>>>>>>>>> one seemed to be maintaining it.
>>>>>>>>>>>
>>>>>>>>>>> There's a new offering in this dept:
>>>>>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
>>>>>>> wrote:
>>>>>>>>>>>> One of the harder things with gitflow is using it in
>> combination
>>>>>>> with
>>>>>>>>>>>> maven. It's ideal that the tags and releases are tracking
>>>>> closely
>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the
>> pom
>>>>>>>>>> version
>>>>>>>>>>>> updated with the git release names.
>>>>>>>>>>>>
>>>>>>>>>>>> Because of the general importance of keeping releases and tags
>>>>>>>>>> synchronized
>>>>>>>>>>>> with the pom version, I think whatever we do, it needs to be
>>>>>>> approached
>>>>>>>>>>>> with tools that are available through maven rather than from
>> git.
>>>>>>> The
>>>>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help deal
>>>>> with
>>>>>>>>>> this
>>>>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
>>>>>>>>>>>>
>>>>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
>>>>> plugin,
>>>>>>> which
>>>>>>>>>>>> does a reasonable job of following the gitflow model for a
>> maven
>>>>>>>>>> project.
>>>>>>>>>>>> I don't recommend this plugin for NIFI, because it insists that
>>>>> the
>>>>>>>>>> master
>>>>>>>>>>>> branch is strictly used for published release tags (as per the
>>>>>>> strict
>>>>>>>>>>>> gitflow workflow). I just mention this, in reference to how
>> some
>>>>>>>>>> plugins
>>>>>>>>>>>> are tackling the gitflow and maven synchronization issue.
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
>>>>> thadguidry@gmail.com
>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
>>>>> become
>>>>>>>>>> primary
>>>>>>>>>>>>> development of next release (with feature branches off of
>> it)..
>>>>>>> while
>>>>>>>>>> you
>>>>>>>>>>>>> continue to have release branches that can have hot fix
>> branches
>>>>>>> off of
>>>>>>>>>>>>> them. (don't use Master as your release branch ! - bad
>>>>> practice !
>>>>>>> )
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone
>> to
>>>>>>>>>>>>> understand... just scroll it down to gain the understanding.
>> Its
>>>>>>> really
>>>>>>>>>>>>> that easy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Most large projects have moved into using git-flow ... and
>> tools
>>>>>>> like
>>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
>>>>>>> built
>>>>>>>>>> in or
>>>>>>>>>>>>> plugin available now. If you want to live on the command
>> line,
>>>>>>> then
>>>>>>>>>> that
>>>>>>>>>>>>> is handled easily by the instructions in the above link.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thad
>>>>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>
Re: [DISCUSS] git branching model
Posted by Aldrin Piri <al...@gmail.com>.
On board with Tony's points. I think the realities of merging in practice
when that "breaking point" of sorts occurs will make the complexity and
overhead quite difficult and maybe even more error prone than the cherry
picking approach with some additional guidelines. When the codebase
drastically changes, the merge conflicts could be quite severe and without
a good knowledge of each part of the codebase involved during that process,
a committer may introduce regressions.
On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc <tr...@gmail.com> wrote:
> the reason I like applying patches to both lines is that once code begins
> to diverge, cleanly merging into one codebase can be impossible. having
> good practices for managing patches and where they apply is paramount for
> success.
>
> I expect that divergence to happen with 1.x. I wanted to get in a battle
> rhythm of sorts of managing multiple lines, even if the patches COULD be
> applied to both in the manner you described.
>
> Joe W and I did a wee bit of scrambling to ensure that tickets marked for
> 0.5.1 had the right patches in the support branch, and some didn't, so I
> think "lesson learned". I do like in the apache infrastructure that if
> commits have the appropriate ticket in their commit message, the jira will
> have the list of commits and branches those commits were applies to.
> However, I think we may need to revisit commit message "hygiene" if we
> relied on this instead of more manual review.
>
>
>
>
>
> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <r....@gmail.com>
> wrote:
>
> > Hi,
> >
> > On a couple of work projects we found that the approach of cherry-picking
> > commits can lead to an unnecessarily complicated history where the same
> > piece of work appears as multiple separate commits on different branches.
> > This can then make it hard to be confident that a bug fix has been
> applied
> > to all relevant branches. We found that it works better to aim to commit
> > changes to the lowest applicable branch, and then regularly merge those
> > branches to master. This approach is based on the git-flow model (
> > http://nvie.com/posts/a-successful-git-branching-model/ <
> > http://nvie.com/posts/a-successful-git-branching-model/>).
> >
> > Looking at the repo there are already a few commits that are duplicated
> on
> > master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1,
> and
> > then that branch would get merged to master.
> >
> > Having the merge commits from the support branch to master makes it
> > explicit in the git history that all bug fixes (and associated tests)
> have
> > been pulled through to master.
> >
> > Cheers,
> > Richard
> >
> > > On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> > >
> > > Thanks, Joe, let me try rephrasing a few of those and see if you agree:
> > >
> > > 1.) Commits merged to master today are destined for the next minor
> > release,
> > > currently 0.6.0, by default?
> > >
> > > By default, commits to master will be released in the next major or
> minor
> > > release. No commits are included in incremental/patch releases by
> > default.
> > >
> > >
> > > 3.) How long will support/0.5.x be maintained?
> > >
> > > support/0.5.x will be maintained until the first of the following
> events:
> > > a.) 0.6.0 is released (next minor release in major release line)
> > > b.) One year after 1.0.0 is released ("previous major release lines up
> to
> > > one year since the last minor release (0.4.y, 1.5.y) in that line")
> > >
> > > But additional support might be available by special request.
> > >
> > >
> > > 4.) Where is compatibility-breaking code destined for a future major
> > > release stored? Is it visible anywhere?
> > >
> > > I suppose Jira tickets targeting the next major release
> > could/should/would
> > > (do?) push branches. That seems weak in the face of a probable
> stampede
> > > towards the fire exit of a major release, but it's a start. I'm not
> > aware
> > > of any great solutions here, certainly not for an open-source project.
> > >
> > >
> > > On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > >> James,
> > >>
> > >> These are great questions to frame and test the model. So let's
> > >> attempt to address them agains the model.
> > >>
> > >> Here is the language for that model at this time:
> > >>
> > >> - 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'
> > >>
> > >> So with those above let's review 1 through 5 in turn.
> > >>
> > >> 1.) Commits merged to master today are destined for the next minor
> > >> release, currently 0.6.0, by default?
> > >>
> > >> Master is for whatever is the most leading edge release line working
> > >> toward the next release. At the time that a minor release occurs
> > >> against that release line then it branches off into a support/x.y.*
> > >> branch for any further efforts against it.
> > >>
> > >> 2.) Is master always open for merging new code, or are there
> > restrictions
> > >> before or after releases?
> > >>
> > >> I believe master would be always open for new code. From some point
> > >> at which a release is considered feature complete then further feature
> > >> enhancements need to go on master as part of the next release effort.
> > >>
> > >> 3.) How long will support/0.5.x be maintained?
> > >>
> > >> The most recent minor release line of a major line will be supported
> > >> for up to one year from whenever it was released where support is for
> > >> bug fixes for security or data loss related items. Releases for older
> > >> minor lines should be considered on a case by case basis and if
> > >> requested. Otherwise the basic premise is the train is moving
> > >> forward.
> > >>
> > >> 4.) Where is compatibility-breaking code destined for a future major
> > >> release stored? Is it visible anywhere?
> > >>
> > >> It must be visible. It should be placed into a branch until such
> > >> time that it is ready to become the new master. That time would be
> > >> when the next release will be for that line. When I think about this
> > >> against the stated model we could probably tweak the wording to better
> > >> articulate that. I think it was what was meant with 'when master has
> > >> no releases we will backport...' but that is unclear.
> > >>
> > >> 5.) A critical data/security bug found after 1.0 would eligible to be
> > >> backported only to the last minor release in the 0.x line, or to all
> > minor
> > >> releases in the 0.x line?
> > >>
> > >> Only to the most recent minor release of any still supported major
> > >> line. However, the catch of 'case by case' determination for older
> > >> minor lines is still in play. Basically if someone requests it and
> > >> can get enough momentum for it then it should be no problem to produce
> > >> such a release.
> > >>
> > >> Thanks
> > >> Joe
> > >>
> > >> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
> > >>> I have some rhetorical questions for discussion of the branching
> model:
> > >>>
> > >>> 1.) Commits merged to master today are destined for the next minor
> > >> release,
> > >>> currently 0.6.0, by default?
> > >>>
> > >>> 2.) Is master always open for merging new code, or are there
> > restrictions
> > >>> before or after releases?
> > >>>
> > >>> 3.) How long will support/0.5.x be maintained?
> > >>>
> > >>> 4.) Where is compatibility-breaking code destined for a future major
> > >>> release stored? Is it visible anywhere?
> > >>>
> > >>> 5.) A critical data/security bug found after 1.0 would eligible to be
> > >>> backported only to the last minor release in the 0.x line, or to all
> > >> minor
> > >>> releases in the 0.x line?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com>
> wrote:
> > >>>
> > >>>> Given the discussion has stalled i'd like to turn it more toward a
> > >>>> proposal as we're at a point now where we need to start executing
> some
> > >>>> of these approaches. We're actually already seeing it take form in
> > >>>> the support/0.5.x branch and the master branch (which is for 0.6.0
> at
> > >>>> this point).
> > >>>>
> > >>>> The proposal then for Git processes based on the other thread [1]
> > >>>> where we outline a support model:
> > >>>>
> > >>>> - 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
> > >>>>
> > >>>> [1]
> > >>>>
> > >>
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> > >>>>
> > >>>> Thanks
> > >>>> Joe
> > >>>>
> > >>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > >>>>> I don't want to kill this thread. It is good to discuss specific
> > >>>>> tooling/procedures. But I do want to get some consensus discussion
> > >>>>> around Tony's original intent (as I read it). So kicked off a
> > >>>>> discussion back at that level.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com>
> wrote:
> > >>>>>> While I like gitflow, I can't say I like any of the plugins that
> are
> > >>>> used.
> > >>>>>> I have worked on some other projects (unfortunately not open
> source)
> > >>>> that
> > >>>>>> use a gitflow inspired workflow, without ever using a plugin. Nice
> > >> side
> > >>>>>> effect is that I believe this got me better at using git, and
> > >> generally
> > >>>> we
> > >>>>>> all got better at managing merge pain.
> > >>>>>>
> > >>>>>> On merge problems, I think the reason we're operating the way we
> are
> > >>>> now is
> > >>>>>> to avoid merge mayhem. I think the initial bar for a patch is "can
> > be
> > >>>>>> merged into master", and we have our friend Travis to make this
> even
> > >>>> easier
> > >>>>>> to know upfront. This greatly simplifies things. If a bugfix is
> > >> "patch
> > >>>>>> needs to be able to apply onto the current release in progress,
> > >> master,
> > >>>> and
> > >>>>>> several other versions we're supporting, with possibly drastically
> > >>>>>> different code", well then things get interesting.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> > >>>> bimargulies@gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> The issue tracker
> > >>>>>>>
> > >>>>>>>
> > >>>>
> > >>
> >
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> > >>>>>>> might also prove useful in evaluating it.
> > >>>>>>>
> > >>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> > >>>>>>> <bi...@gmail.com> wrote:
> > >>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
> > >> until
> > >>>> it
> > >>>>>>>> didn't. It would get into terrible, inexplicable, merge
> problems.
> > >> No
> > >>>>>>>> one seemed to be maintaining it.
> > >>>>>>>>
> > >>>>>>>> There's a new offering in this dept:
> > >>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> > >>>>>>>>
> > >>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
> > >>>> wrote:
> > >>>>>>>>> One of the harder things with gitflow is using it in
> combination
> > >>>> with
> > >>>>>>>>> maven. It's ideal that the tags and releases are tracking
> > >> closely
> > >>>> with
> > >>>>>>> the
> > >>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the
> pom
> > >>>>>>> version
> > >>>>>>>>> updated with the git release names.
> > >>>>>>>>>
> > >>>>>>>>> Because of the general importance of keeping releases and tags
> > >>>>>>> synchronized
> > >>>>>>>>> with the pom version, I think whatever we do, it needs to be
> > >>>> approached
> > >>>>>>>>> with tools that are available through maven rather than from
> git.
> > >>>> The
> > >>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help deal
> > >> with
> > >>>>>>> this
> > >>>>>>>>> synchronization, since it's a git tool, not a maven tool.
> > >>>>>>>>>
> > >>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
> > >> plugin,
> > >>>> which
> > >>>>>>>>> does a reasonable job of following the gitflow model for a
> maven
> > >>>>>>> project.
> > >>>>>>>>> I don't recommend this plugin for NIFI, because it insists that
> > >> the
> > >>>>>>> master
> > >>>>>>>>> branch is strictly used for published release tags (as per the
> > >>>> strict
> > >>>>>>>>> gitflow workflow). I just mention this, in reference to how
> some
> > >>>>>>> plugins
> > >>>>>>>>> are tackling the gitflow and maven synchronization issue.
> > >>>>>>>>>
> > >>>>>>>>> [1] http://jgitflow.bitbucket.org/
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> > >> thadguidry@gmail.com
> > >>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
> > >> become
> > >>>>>>> primary
> > >>>>>>>>>> development of next release (with feature branches off of
> it)..
> > >>>> while
> > >>>>>>> you
> > >>>>>>>>>> continue to have release branches that can have hot fix
> branches
> > >>>> off of
> > >>>>>>>>>> them. (don't use Master as your release branch ! - bad
> > >> practice !
> > >>>> )
> > >>>>>>>>>>
> > >>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone
> to
> > >>>>>>>>>> understand... just scroll it down to gain the understanding.
> Its
> > >>>> really
> > >>>>>>>>>> that easy.
> > >>>>>>>>>>
> > >>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> > >>>>>>>>>>
> > >>>>>>>>>> Most large projects have moved into using git-flow ... and
> tools
> > >>>> like
> > >>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
> > >>>> built
> > >>>>>>> in or
> > >>>>>>>>>> plugin available now. If you want to live on the command
> line,
> > >>>> then
> > >>>>>>> that
> > >>>>>>>>>> is handled easily by the instructions in the above link.
> > >>>>>>>>>>
> > >>>>>>>>>> Thad
> > >>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> > >>>>>>>>>>
> > >>>>>>>
> > >>>>
> > >>
> >
> >
>
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
the reason I like applying patches to both lines is that once code begins
to diverge, cleanly merging into one codebase can be impossible. having
good practices for managing patches and where they apply is paramount for
success.
I expect that divergence to happen with 1.x. I wanted to get in a battle
rhythm of sorts of managing multiple lines, even if the patches COULD be
applied to both in the manner you described.
Joe W and I did a wee bit of scrambling to ensure that tickets marked for
0.5.1 had the right patches in the support branch, and some didn't, so I
think "lesson learned". I do like in the apache infrastructure that if
commits have the appropriate ticket in their commit message, the jira will
have the list of commits and branches those commits were applies to.
However, I think we may need to revisit commit message "hygiene" if we
relied on this instead of more manual review.
On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin <r....@gmail.com>
wrote:
> Hi,
>
> On a couple of work projects we found that the approach of cherry-picking
> commits can lead to an unnecessarily complicated history where the same
> piece of work appears as multiple separate commits on different branches.
> This can then make it hard to be confident that a bug fix has been applied
> to all relevant branches. We found that it works better to aim to commit
> changes to the lowest applicable branch, and then regularly merge those
> branches to master. This approach is based on the git-flow model (
> http://nvie.com/posts/a-successful-git-branching-model/ <
> http://nvie.com/posts/a-successful-git-branching-model/>).
>
> Looking at the repo there are already a few commits that are duplicated on
> master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1, and
> then that branch would get merged to master.
>
> Having the merge commits from the support branch to master makes it
> explicit in the git history that all bug fixes (and associated tests) have
> been pulled through to master.
>
> Cheers,
> Richard
>
> > On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
> >
> > Thanks, Joe, let me try rephrasing a few of those and see if you agree:
> >
> > 1.) Commits merged to master today are destined for the next minor
> release,
> > currently 0.6.0, by default?
> >
> > By default, commits to master will be released in the next major or minor
> > release. No commits are included in incremental/patch releases by
> default.
> >
> >
> > 3.) How long will support/0.5.x be maintained?
> >
> > support/0.5.x will be maintained until the first of the following events:
> > a.) 0.6.0 is released (next minor release in major release line)
> > b.) One year after 1.0.0 is released ("previous major release lines up to
> > one year since the last minor release (0.4.y, 1.5.y) in that line")
> >
> > But additional support might be available by special request.
> >
> >
> > 4.) Where is compatibility-breaking code destined for a future major
> > release stored? Is it visible anywhere?
> >
> > I suppose Jira tickets targeting the next major release
> could/should/would
> > (do?) push branches. That seems weak in the face of a probable stampede
> > towards the fire exit of a major release, but it's a start. I'm not
> aware
> > of any great solutions here, certainly not for an open-source project.
> >
> >
> > On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> >> James,
> >>
> >> These are great questions to frame and test the model. So let's
> >> attempt to address them agains the model.
> >>
> >> Here is the language for that model at this time:
> >>
> >> - 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'
> >>
> >> So with those above let's review 1 through 5 in turn.
> >>
> >> 1.) Commits merged to master today are destined for the next minor
> >> release, currently 0.6.0, by default?
> >>
> >> Master is for whatever is the most leading edge release line working
> >> toward the next release. At the time that a minor release occurs
> >> against that release line then it branches off into a support/x.y.*
> >> branch for any further efforts against it.
> >>
> >> 2.) Is master always open for merging new code, or are there
> restrictions
> >> before or after releases?
> >>
> >> I believe master would be always open for new code. From some point
> >> at which a release is considered feature complete then further feature
> >> enhancements need to go on master as part of the next release effort.
> >>
> >> 3.) How long will support/0.5.x be maintained?
> >>
> >> The most recent minor release line of a major line will be supported
> >> for up to one year from whenever it was released where support is for
> >> bug fixes for security or data loss related items. Releases for older
> >> minor lines should be considered on a case by case basis and if
> >> requested. Otherwise the basic premise is the train is moving
> >> forward.
> >>
> >> 4.) Where is compatibility-breaking code destined for a future major
> >> release stored? Is it visible anywhere?
> >>
> >> It must be visible. It should be placed into a branch until such
> >> time that it is ready to become the new master. That time would be
> >> when the next release will be for that line. When I think about this
> >> against the stated model we could probably tweak the wording to better
> >> articulate that. I think it was what was meant with 'when master has
> >> no releases we will backport...' but that is unclear.
> >>
> >> 5.) A critical data/security bug found after 1.0 would eligible to be
> >> backported only to the last minor release in the 0.x line, or to all
> minor
> >> releases in the 0.x line?
> >>
> >> Only to the most recent minor release of any still supported major
> >> line. However, the catch of 'case by case' determination for older
> >> minor lines is still in play. Basically if someone requests it and
> >> can get enough momentum for it then it should be no problem to produce
> >> such a release.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
> >>> I have some rhetorical questions for discussion of the branching model:
> >>>
> >>> 1.) Commits merged to master today are destined for the next minor
> >> release,
> >>> currently 0.6.0, by default?
> >>>
> >>> 2.) Is master always open for merging new code, or are there
> restrictions
> >>> before or after releases?
> >>>
> >>> 3.) How long will support/0.5.x be maintained?
> >>>
> >>> 4.) Where is compatibility-breaking code destined for a future major
> >>> release stored? Is it visible anywhere?
> >>>
> >>> 5.) A critical data/security bug found after 1.0 would eligible to be
> >>> backported only to the last minor release in the 0.x line, or to all
> >> minor
> >>> releases in the 0.x line?
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>
> >>>> Given the discussion has stalled i'd like to turn it more toward a
> >>>> proposal as we're at a point now where we need to start executing some
> >>>> of these approaches. We're actually already seeing it take form in
> >>>> the support/0.5.x branch and the master branch (which is for 0.6.0 at
> >>>> this point).
> >>>>
> >>>> The proposal then for Git processes based on the other thread [1]
> >>>> where we outline a support model:
> >>>>
> >>>> - 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
> >>>>
> >>>> [1]
> >>>>
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >>>>
> >>>> Thanks
> >>>> Joe
> >>>>
> >>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
> >>>>> I don't want to kill this thread. It is good to discuss specific
> >>>>> tooling/procedures. But I do want to get some consensus discussion
> >>>>> around Tony's original intent (as I read it). So kicked off a
> >>>>> discussion back at that level.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
> >>>>>> While I like gitflow, I can't say I like any of the plugins that are
> >>>> used.
> >>>>>> I have worked on some other projects (unfortunately not open source)
> >>>> that
> >>>>>> use a gitflow inspired workflow, without ever using a plugin. Nice
> >> side
> >>>>>> effect is that I believe this got me better at using git, and
> >> generally
> >>>> we
> >>>>>> all got better at managing merge pain.
> >>>>>>
> >>>>>> On merge problems, I think the reason we're operating the way we are
> >>>> now is
> >>>>>> to avoid merge mayhem. I think the initial bar for a patch is "can
> be
> >>>>>> merged into master", and we have our friend Travis to make this even
> >>>> easier
> >>>>>> to know upfront. This greatly simplifies things. If a bugfix is
> >> "patch
> >>>>>> needs to be able to apply onto the current release in progress,
> >> master,
> >>>> and
> >>>>>> several other versions we're supporting, with possibly drastically
> >>>>>> different code", well then things get interesting.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> >>>> bimargulies@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> The issue tracker
> >>>>>>>
> >>>>>>>
> >>>>
> >>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >>>>>>> might also prove useful in evaluating it.
> >>>>>>>
> >>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> >>>>>>> <bi...@gmail.com> wrote:
> >>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
> >> until
> >>>> it
> >>>>>>>> didn't. It would get into terrible, inexplicable, merge problems.
> >> No
> >>>>>>>> one seemed to be maintaining it.
> >>>>>>>>
> >>>>>>>> There's a new offering in this dept:
> >>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >>>>>>>>
> >>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
> >>>> wrote:
> >>>>>>>>> One of the harder things with gitflow is using it in combination
> >>>> with
> >>>>>>>>> maven. It's ideal that the tags and releases are tracking
> >> closely
> >>>> with
> >>>>>>> the
> >>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the pom
> >>>>>>> version
> >>>>>>>>> updated with the git release names.
> >>>>>>>>>
> >>>>>>>>> Because of the general importance of keeping releases and tags
> >>>>>>> synchronized
> >>>>>>>>> with the pom version, I think whatever we do, it needs to be
> >>>> approached
> >>>>>>>>> with tools that are available through maven rather than from git.
> >>>> The
> >>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help deal
> >> with
> >>>>>>> this
> >>>>>>>>> synchronization, since it's a git tool, not a maven tool.
> >>>>>>>>>
> >>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
> >> plugin,
> >>>> which
> >>>>>>>>> does a reasonable job of following the gitflow model for a maven
> >>>>>>> project.
> >>>>>>>>> I don't recommend this plugin for NIFI, because it insists that
> >> the
> >>>>>>> master
> >>>>>>>>> branch is strictly used for published release tags (as per the
> >>>> strict
> >>>>>>>>> gitflow workflow). I just mention this, in reference to how some
> >>>>>>> plugins
> >>>>>>>>> are tackling the gitflow and maven synchronization issue.
> >>>>>>>>>
> >>>>>>>>> [1] http://jgitflow.bitbucket.org/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> >> thadguidry@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
> >> become
> >>>>>>> primary
> >>>>>>>>>> development of next release (with feature branches off of it)..
> >>>> while
> >>>>>>> you
> >>>>>>>>>> continue to have release branches that can have hot fix branches
> >>>> off of
> >>>>>>>>>> them. (don't use Master as your release branch ! - bad
> >> practice !
> >>>> )
> >>>>>>>>>>
> >>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone to
> >>>>>>>>>> understand... just scroll it down to gain the understanding. Its
> >>>> really
> >>>>>>>>>> that easy.
> >>>>>>>>>>
> >>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>>>>>>>>>
> >>>>>>>>>> Most large projects have moved into using git-flow ... and tools
> >>>> like
> >>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
> >>>> built
> >>>>>>> in or
> >>>>>>>>>> plugin available now. If you want to live on the command line,
> >>>> then
> >>>>>>> that
> >>>>>>>>>> is handled easily by the instructions in the above link.
> >>>>>>>>>>
> >>>>>>>>>> Thad
> >>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >>>>>>>>>>
> >>>>>>>
> >>>>
> >>
>
>
Re: [DISCUSS] git branching model
Posted by Richard Miskin <r....@gmail.com>.
Hi,
On a couple of work projects we found that the approach of cherry-picking commits can lead to an unnecessarily complicated history where the same piece of work appears as multiple separate commits on different branches. This can then make it hard to be confident that a bug fix has been applied to all relevant branches. We found that it works better to aim to commit changes to the lowest applicable branch, and then regularly merge those branches to master. This approach is based on the git-flow model (http://nvie.com/posts/a-successful-git-branching-model/ <http://nvie.com/posts/a-successful-git-branching-model/>).
Looking at the repo there are already a few commits that are duplicated on master and 0.5.1. Using the model I suggest they’d only occur on 0.5.1, and then that branch would get merged to master.
Having the merge commits from the support branch to master makes it explicit in the git history that all bug fixes (and associated tests) have been pulled through to master.
Cheers,
Richard
> On 26 Feb 2016, at 06:59, James Wing <jv...@gmail.com> wrote:
>
> Thanks, Joe, let me try rephrasing a few of those and see if you agree:
>
> 1.) Commits merged to master today are destined for the next minor release,
> currently 0.6.0, by default?
>
> By default, commits to master will be released in the next major or minor
> release. No commits are included in incremental/patch releases by default.
>
>
> 3.) How long will support/0.5.x be maintained?
>
> support/0.5.x will be maintained until the first of the following events:
> a.) 0.6.0 is released (next minor release in major release line)
> b.) One year after 1.0.0 is released ("previous major release lines up to
> one year since the last minor release (0.4.y, 1.5.y) in that line")
>
> But additional support might be available by special request.
>
>
> 4.) Where is compatibility-breaking code destined for a future major
> release stored? Is it visible anywhere?
>
> I suppose Jira tickets targeting the next major release could/should/would
> (do?) push branches. That seems weak in the face of a probable stampede
> towards the fire exit of a major release, but it's a start. I'm not aware
> of any great solutions here, certainly not for an open-source project.
>
>
> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> James,
>>
>> These are great questions to frame and test the model. So let's
>> attempt to address them agains the model.
>>
>> Here is the language for that model at this time:
>>
>> - 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'
>>
>> So with those above let's review 1 through 5 in turn.
>>
>> 1.) Commits merged to master today are destined for the next minor
>> release, currently 0.6.0, by default?
>>
>> Master is for whatever is the most leading edge release line working
>> toward the next release. At the time that a minor release occurs
>> against that release line then it branches off into a support/x.y.*
>> branch for any further efforts against it.
>>
>> 2.) Is master always open for merging new code, or are there restrictions
>> before or after releases?
>>
>> I believe master would be always open for new code. From some point
>> at which a release is considered feature complete then further feature
>> enhancements need to go on master as part of the next release effort.
>>
>> 3.) How long will support/0.5.x be maintained?
>>
>> The most recent minor release line of a major line will be supported
>> for up to one year from whenever it was released where support is for
>> bug fixes for security or data loss related items. Releases for older
>> minor lines should be considered on a case by case basis and if
>> requested. Otherwise the basic premise is the train is moving
>> forward.
>>
>> 4.) Where is compatibility-breaking code destined for a future major
>> release stored? Is it visible anywhere?
>>
>> It must be visible. It should be placed into a branch until such
>> time that it is ready to become the new master. That time would be
>> when the next release will be for that line. When I think about this
>> against the stated model we could probably tweak the wording to better
>> articulate that. I think it was what was meant with 'when master has
>> no releases we will backport...' but that is unclear.
>>
>> 5.) A critical data/security bug found after 1.0 would eligible to be
>> backported only to the last minor release in the 0.x line, or to all minor
>> releases in the 0.x line?
>>
>> Only to the most recent minor release of any still supported major
>> line. However, the catch of 'case by case' determination for older
>> minor lines is still in play. Basically if someone requests it and
>> can get enough momentum for it then it should be no problem to produce
>> such a release.
>>
>> Thanks
>> Joe
>>
>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
>>> I have some rhetorical questions for discussion of the branching model:
>>>
>>> 1.) Commits merged to master today are destined for the next minor
>> release,
>>> currently 0.6.0, by default?
>>>
>>> 2.) Is master always open for merging new code, or are there restrictions
>>> before or after releases?
>>>
>>> 3.) How long will support/0.5.x be maintained?
>>>
>>> 4.) Where is compatibility-breaking code destined for a future major
>>> release stored? Is it visible anywhere?
>>>
>>> 5.) A critical data/security bug found after 1.0 would eligible to be
>>> backported only to the last minor release in the 0.x line, or to all
>> minor
>>> releases in the 0.x line?
>>>
>>>
>>>
>>>
>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com> wrote:
>>>
>>>> Given the discussion has stalled i'd like to turn it more toward a
>>>> proposal as we're at a point now where we need to start executing some
>>>> of these approaches. We're actually already seeing it take form in
>>>> the support/0.5.x branch and the master branch (which is for 0.6.0 at
>>>> this point).
>>>>
>>>> The proposal then for Git processes based on the other thread [1]
>>>> where we outline a support model:
>>>>
>>>> - 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
>>>>
>>>> [1]
>>>>
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>> I don't want to kill this thread. It is good to discuss specific
>>>>> tooling/procedures. But I do want to get some consensus discussion
>>>>> around Tony's original intent (as I read it). So kicked off a
>>>>> discussion back at that level.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
>>>>>> While I like gitflow, I can't say I like any of the plugins that are
>>>> used.
>>>>>> I have worked on some other projects (unfortunately not open source)
>>>> that
>>>>>> use a gitflow inspired workflow, without ever using a plugin. Nice
>> side
>>>>>> effect is that I believe this got me better at using git, and
>> generally
>>>> we
>>>>>> all got better at managing merge pain.
>>>>>>
>>>>>> On merge problems, I think the reason we're operating the way we are
>>>> now is
>>>>>> to avoid merge mayhem. I think the initial bar for a patch is "can be
>>>>>> merged into master", and we have our friend Travis to make this even
>>>> easier
>>>>>> to know upfront. This greatly simplifies things. If a bugfix is
>> "patch
>>>>>> needs to be able to apply onto the current release in progress,
>> master,
>>>> and
>>>>>> several other versions we're supporting, with possibly drastically
>>>>>> different code", well then things get interesting.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>>>> bimargulies@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The issue tracker
>>>>>>>
>>>>>>>
>>>>
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>>>>>>> might also prove useful in evaluating it.
>>>>>>>
>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>>>>>>> <bi...@gmail.com> wrote:
>>>>>>>> I tried to use the bitbucket gitflow plugin. It worked great,
>> until
>>>> it
>>>>>>>> didn't. It would get into terrible, inexplicable, merge problems.
>> No
>>>>>>>> one seemed to be maintaining it.
>>>>>>>>
>>>>>>>> There's a new offering in this dept:
>>>>>>>> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>>>>>>>>
>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
>>>> wrote:
>>>>>>>>> One of the harder things with gitflow is using it in combination
>>>> with
>>>>>>>>> maven. It's ideal that the tags and releases are tracking
>> closely
>>>> with
>>>>>>> the
>>>>>>>>> maven pom.xml version. gitflow, on its own, doesn't keep the pom
>>>>>>> version
>>>>>>>>> updated with the git release names.
>>>>>>>>>
>>>>>>>>> Because of the general importance of keeping releases and tags
>>>>>>> synchronized
>>>>>>>>> with the pom version, I think whatever we do, it needs to be
>>>> approached
>>>>>>>>> with tools that are available through maven rather than from git.
>>>> The
>>>>>>>>> git-flow plugin (referenced by Thad) doesn't directly help deal
>> with
>>>>>>> this
>>>>>>>>> synchronization, since it's a git tool, not a maven tool.
>>>>>>>>>
>>>>>>>>> I've been using, with reasonable success, the jgitflow [1]
>> plugin,
>>>> which
>>>>>>>>> does a reasonable job of following the gitflow model for a maven
>>>>>>> project.
>>>>>>>>> I don't recommend this plugin for NIFI, because it insists that
>> the
>>>>>>> master
>>>>>>>>> branch is strictly used for published release tags (as per the
>>>> strict
>>>>>>>>> gitflow workflow). I just mention this, in reference to how some
>>>>>>> plugins
>>>>>>>>> are tackling the gitflow and maven synchronization issue.
>>>>>>>>>
>>>>>>>>> [1] http://jgitflow.bitbucket.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
>> thadguidry@gmail.com
>>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Your on the right track / idea with Git-flow. Your Master
>> become
>>>>>>> primary
>>>>>>>>>> development of next release (with feature branches off of it)..
>>>> while
>>>>>>> you
>>>>>>>>>> continue to have release branches that can have hot fix branches
>>>> off of
>>>>>>>>>> them. (don't use Master as your release branch ! - bad
>> practice !
>>>> )
>>>>>>>>>>
>>>>>>>>>> Here is the Git-flow cheat sheet to make it easy for everyone to
>>>>>>>>>> understand... just scroll it down to gain the understanding. Its
>>>> really
>>>>>>>>>> that easy.
>>>>>>>>>>
>>>>>>>>>> http://danielkummer.github.io/git-flow-cheatsheet/
>>>>>>>>>>
>>>>>>>>>> Most large projects have moved into using git-flow ... and tools
>>>> like
>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
>>>> built
>>>>>>> in or
>>>>>>>>>> plugin available now. If you want to live on the command line,
>>>> then
>>>>>>> that
>>>>>>>>>> is handled easily by the instructions in the above link.
>>>>>>>>>>
>>>>>>>>>> Thad
>>>>>>>>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>>>>>>>>>
>>>>>>>
>>>>
>>
Re: [DISCUSS] git branching model
Posted by James Wing <jv...@gmail.com>.
Thanks, Joe, let me try rephrasing a few of those and see if you agree:
1.) Commits merged to master today are destined for the next minor release,
currently 0.6.0, by default?
By default, commits to master will be released in the next major or minor
release. No commits are included in incremental/patch releases by default.
3.) How long will support/0.5.x be maintained?
support/0.5.x will be maintained until the first of the following events:
a.) 0.6.0 is released (next minor release in major release line)
b.) One year after 1.0.0 is released ("previous major release lines up to
one year since the last minor release (0.4.y, 1.5.y) in that line")
But additional support might be available by special request.
4.) Where is compatibility-breaking code destined for a future major
release stored? Is it visible anywhere?
I suppose Jira tickets targeting the next major release could/should/would
(do?) push branches. That seems weak in the face of a probable stampede
towards the fire exit of a major release, but it's a start. I'm not aware
of any great solutions here, certainly not for an open-source project.
On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt <jo...@gmail.com> wrote:
> James,
>
> These are great questions to frame and test the model. So let's
> attempt to address them agains the model.
>
> Here is the language for that model at this time:
>
> - 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'
>
> So with those above let's review 1 through 5 in turn.
>
> 1.) Commits merged to master today are destined for the next minor
> release, currently 0.6.0, by default?
>
> Master is for whatever is the most leading edge release line working
> toward the next release. At the time that a minor release occurs
> against that release line then it branches off into a support/x.y.*
> branch for any further efforts against it.
>
> 2.) Is master always open for merging new code, or are there restrictions
> before or after releases?
>
> I believe master would be always open for new code. From some point
> at which a release is considered feature complete then further feature
> enhancements need to go on master as part of the next release effort.
>
> 3.) How long will support/0.5.x be maintained?
>
> The most recent minor release line of a major line will be supported
> for up to one year from whenever it was released where support is for
> bug fixes for security or data loss related items. Releases for older
> minor lines should be considered on a case by case basis and if
> requested. Otherwise the basic premise is the train is moving
> forward.
>
> 4.) Where is compatibility-breaking code destined for a future major
> release stored? Is it visible anywhere?
>
> It must be visible. It should be placed into a branch until such
> time that it is ready to become the new master. That time would be
> when the next release will be for that line. When I think about this
> against the stated model we could probably tweak the wording to better
> articulate that. I think it was what was meant with 'when master has
> no releases we will backport...' but that is unclear.
>
> 5.) A critical data/security bug found after 1.0 would eligible to be
> backported only to the last minor release in the 0.x line, or to all minor
> releases in the 0.x line?
>
> Only to the most recent minor release of any still supported major
> line. However, the catch of 'case by case' determination for older
> minor lines is still in play. Basically if someone requests it and
> can get enough momentum for it then it should be no problem to produce
> such a release.
>
> Thanks
> Joe
>
> On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
> > I have some rhetorical questions for discussion of the branching model:
> >
> > 1.) Commits merged to master today are destined for the next minor
> release,
> > currently 0.6.0, by default?
> >
> > 2.) Is master always open for merging new code, or are there restrictions
> > before or after releases?
> >
> > 3.) How long will support/0.5.x be maintained?
> >
> > 4.) Where is compatibility-breaking code destined for a future major
> > release stored? Is it visible anywhere?
> >
> > 5.) A critical data/security bug found after 1.0 would eligible to be
> > backported only to the last minor release in the 0.x line, or to all
> minor
> > releases in the 0.x line?
> >
> >
> >
> >
> > On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> >> Given the discussion has stalled i'd like to turn it more toward a
> >> proposal as we're at a point now where we need to start executing some
> >> of these approaches. We're actually already seeing it take form in
> >> the support/0.5.x branch and the master branch (which is for 0.6.0 at
> >> this point).
> >>
> >> The proposal then for Git processes based on the other thread [1]
> >> where we outline a support model:
> >>
> >> - 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
> >>
> >> [1]
> >>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
> >>
> >> Thanks
> >> Joe
> >>
> >> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
> >> > I don't want to kill this thread. It is good to discuss specific
> >> > tooling/procedures. But I do want to get some consensus discussion
> >> > around Tony's original intent (as I read it). So kicked off a
> >> > discussion back at that level.
> >> >
> >> >
> >> >
> >> > On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
> >> >> While I like gitflow, I can't say I like any of the plugins that are
> >> used.
> >> >> I have worked on some other projects (unfortunately not open source)
> >> that
> >> >> use a gitflow inspired workflow, without ever using a plugin. Nice
> side
> >> >> effect is that I believe this got me better at using git, and
> generally
> >> we
> >> >> all got better at managing merge pain.
> >> >>
> >> >> On merge problems, I think the reason we're operating the way we are
> >> now is
> >> >> to avoid merge mayhem. I think the initial bar for a patch is "can be
> >> >> merged into master", and we have our friend Travis to make this even
> >> easier
> >> >> to know upfront. This greatly simplifies things. If a bugfix is
> "patch
> >> >> needs to be able to apply onto the current release in progress,
> master,
> >> and
> >> >> several other versions we're supporting, with possibly drastically
> >> >> different code", well then things get interesting.
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> >> bimargulies@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> The issue tracker
> >> >>>
> >> >>>
> >>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >> >>> might also prove useful in evaluating it.
> >> >>>
> >> >>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> >> >>> <bi...@gmail.com> wrote:
> >> >>> > I tried to use the bitbucket gitflow plugin. It worked great,
> until
> >> it
> >> >>> > didn't. It would get into terrible, inexplicable, merge problems.
> No
> >> >>> > one seemed to be maintaining it.
> >> >>> >
> >> >>> > There's a new offering in this dept:
> >> >>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >> >>> >
> >> >>> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
> >> wrote:
> >> >>> >> One of the harder things with gitflow is using it in combination
> >> with
> >> >>> >> maven. It's ideal that the tags and releases are tracking
> closely
> >> with
> >> >>> the
> >> >>> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
> >> >>> version
> >> >>> >> updated with the git release names.
> >> >>> >>
> >> >>> >> Because of the general importance of keeping releases and tags
> >> >>> synchronized
> >> >>> >> with the pom version, I think whatever we do, it needs to be
> >> approached
> >> >>> >> with tools that are available through maven rather than from git.
> >> The
> >> >>> >> git-flow plugin (referenced by Thad) doesn't directly help deal
> with
> >> >>> this
> >> >>> >> synchronization, since it's a git tool, not a maven tool.
> >> >>> >>
> >> >>> >> I've been using, with reasonable success, the jgitflow [1]
> plugin,
> >> which
> >> >>> >> does a reasonable job of following the gitflow model for a maven
> >> >>> project.
> >> >>> >> I don't recommend this plugin for NIFI, because it insists that
> the
> >> >>> master
> >> >>> >> branch is strictly used for published release tags (as per the
> >> strict
> >> >>> >> gitflow workflow). I just mention this, in reference to how some
> >> >>> plugins
> >> >>> >> are tackling the gitflow and maven synchronization issue.
> >> >>> >>
> >> >>> >> [1] http://jgitflow.bitbucket.org/
> >> >>> >>
> >> >>> >>
> >> >>> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <
> thadguidry@gmail.com
> >> >
> >> >>> wrote:
> >> >>> >>
> >> >>> >>> Your on the right track / idea with Git-flow. Your Master
> become
> >> >>> primary
> >> >>> >>> development of next release (with feature branches off of it)..
> >> while
> >> >>> you
> >> >>> >>> continue to have release branches that can have hot fix branches
> >> off of
> >> >>> >>> them. (don't use Master as your release branch ! - bad
> practice !
> >> )
> >> >>> >>>
> >> >>> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
> >> >>> >>> understand... just scroll it down to gain the understanding. Its
> >> really
> >> >>> >>> that easy.
> >> >>> >>>
> >> >>> >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >> >>> >>>
> >> >>> >>> Most large projects have moved into using git-flow ... and tools
> >> like
> >> >>> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
> >> built
> >> >>> in or
> >> >>> >>> plugin available now. If you want to live on the command line,
> >> then
> >> >>> that
> >> >>> >>> is handled easily by the instructions in the above link.
> >> >>> >>>
> >> >>> >>> Thad
> >> >>> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >> >>> >>>
> >> >>>
> >>
>
Re: [DISCUSS] git branching model
Posted by Joe Witt <jo...@gmail.com>.
James,
These are great questions to frame and test the model. So let's
attempt to address them agains the model.
Here is the language for that model at this time:
- 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'
So with those above let's review 1 through 5 in turn.
1.) Commits merged to master today are destined for the next minor
release, currently 0.6.0, by default?
Master is for whatever is the most leading edge release line working
toward the next release. At the time that a minor release occurs
against that release line then it branches off into a support/x.y.*
branch for any further efforts against it.
2.) Is master always open for merging new code, or are there restrictions
before or after releases?
I believe master would be always open for new code. From some point
at which a release is considered feature complete then further feature
enhancements need to go on master as part of the next release effort.
3.) How long will support/0.5.x be maintained?
The most recent minor release line of a major line will be supported
for up to one year from whenever it was released where support is for
bug fixes for security or data loss related items. Releases for older
minor lines should be considered on a case by case basis and if
requested. Otherwise the basic premise is the train is moving
forward.
4.) Where is compatibility-breaking code destined for a future major
release stored? Is it visible anywhere?
It must be visible. It should be placed into a branch until such
time that it is ready to become the new master. That time would be
when the next release will be for that line. When I think about this
against the stated model we could probably tweak the wording to better
articulate that. I think it was what was meant with 'when master has
no releases we will backport...' but that is unclear.
5.) A critical data/security bug found after 1.0 would eligible to be
backported only to the last minor release in the 0.x line, or to all minor
releases in the 0.x line?
Only to the most recent minor release of any still supported major
line. However, the catch of 'case by case' determination for older
minor lines is still in play. Basically if someone requests it and
can get enough momentum for it then it should be no problem to produce
such a release.
Thanks
Joe
On Thu, Feb 25, 2016 at 3:15 PM, James Wing <jv...@gmail.com> wrote:
> I have some rhetorical questions for discussion of the branching model:
>
> 1.) Commits merged to master today are destined for the next minor release,
> currently 0.6.0, by default?
>
> 2.) Is master always open for merging new code, or are there restrictions
> before or after releases?
>
> 3.) How long will support/0.5.x be maintained?
>
> 4.) Where is compatibility-breaking code destined for a future major
> release stored? Is it visible anywhere?
>
> 5.) A critical data/security bug found after 1.0 would eligible to be
> backported only to the last minor release in the 0.x line, or to all minor
> releases in the 0.x line?
>
>
>
>
> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com> wrote:
>
>> Given the discussion has stalled i'd like to turn it more toward a
>> proposal as we're at a point now where we need to start executing some
>> of these approaches. We're actually already seeing it take form in
>> the support/0.5.x branch and the master branch (which is for 0.6.0 at
>> this point).
>>
>> The proposal then for Git processes based on the other thread [1]
>> where we outline a support model:
>>
>> - 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
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>>
>> Thanks
>> Joe
>>
>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
>> > I don't want to kill this thread. It is good to discuss specific
>> > tooling/procedures. But I do want to get some consensus discussion
>> > around Tony's original intent (as I read it). So kicked off a
>> > discussion back at that level.
>> >
>> >
>> >
>> > On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
>> >> While I like gitflow, I can't say I like any of the plugins that are
>> used.
>> >> I have worked on some other projects (unfortunately not open source)
>> that
>> >> use a gitflow inspired workflow, without ever using a plugin. Nice side
>> >> effect is that I believe this got me better at using git, and generally
>> we
>> >> all got better at managing merge pain.
>> >>
>> >> On merge problems, I think the reason we're operating the way we are
>> now is
>> >> to avoid merge mayhem. I think the initial bar for a patch is "can be
>> >> merged into master", and we have our friend Travis to make this even
>> easier
>> >> to know upfront. This greatly simplifies things. If a bugfix is "patch
>> >> needs to be able to apply onto the current release in progress, master,
>> and
>> >> several other versions we're supporting, with possibly drastically
>> >> different code", well then things get interesting.
>> >>
>> >>
>> >>
>> >> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
>> bimargulies@gmail.com>
>> >> wrote:
>> >>
>> >>> The issue tracker
>> >>>
>> >>>
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>> >>> might also prove useful in evaluating it.
>> >>>
>> >>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>> >>> <bi...@gmail.com> wrote:
>> >>> > I tried to use the bitbucket gitflow plugin. It worked great, until
>> it
>> >>> > didn't. It would get into terrible, inexplicable, merge problems. No
>> >>> > one seemed to be maintaining it.
>> >>> >
>> >>> > There's a new offering in this dept:
>> >>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>> >>> >
>> >>> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
>> wrote:
>> >>> >> One of the harder things with gitflow is using it in combination
>> with
>> >>> >> maven. It's ideal that the tags and releases are tracking closely
>> with
>> >>> the
>> >>> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
>> >>> version
>> >>> >> updated with the git release names.
>> >>> >>
>> >>> >> Because of the general importance of keeping releases and tags
>> >>> synchronized
>> >>> >> with the pom version, I think whatever we do, it needs to be
>> approached
>> >>> >> with tools that are available through maven rather than from git.
>> The
>> >>> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
>> >>> this
>> >>> >> synchronization, since it's a git tool, not a maven tool.
>> >>> >>
>> >>> >> I've been using, with reasonable success, the jgitflow [1] plugin,
>> which
>> >>> >> does a reasonable job of following the gitflow model for a maven
>> >>> project.
>> >>> >> I don't recommend this plugin for NIFI, because it insists that the
>> >>> master
>> >>> >> branch is strictly used for published release tags (as per the
>> strict
>> >>> >> gitflow workflow). I just mention this, in reference to how some
>> >>> plugins
>> >>> >> are tackling the gitflow and maven synchronization issue.
>> >>> >>
>> >>> >> [1] http://jgitflow.bitbucket.org/
>> >>> >>
>> >>> >>
>> >>> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <thadguidry@gmail.com
>> >
>> >>> wrote:
>> >>> >>
>> >>> >>> Your on the right track / idea with Git-flow. Your Master become
>> >>> primary
>> >>> >>> development of next release (with feature branches off of it)..
>> while
>> >>> you
>> >>> >>> continue to have release branches that can have hot fix branches
>> off of
>> >>> >>> them. (don't use Master as your release branch ! - bad practice !
>> )
>> >>> >>>
>> >>> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
>> >>> >>> understand... just scroll it down to gain the understanding. Its
>> really
>> >>> >>> that easy.
>> >>> >>>
>> >>> >>> http://danielkummer.github.io/git-flow-cheatsheet/
>> >>> >>>
>> >>> >>> Most large projects have moved into using git-flow ... and tools
>> like
>> >>> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
>> built
>> >>> in or
>> >>> >>> plugin available now. If you want to live on the command line,
>> then
>> >>> that
>> >>> >>> is handled easily by the instructions in the above link.
>> >>> >>>
>> >>> >>> Thad
>> >>> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>> >>> >>>
>> >>>
>>
Re: [DISCUSS] git branching model
Posted by James Wing <jv...@gmail.com>.
I have some rhetorical questions for discussion of the branching model:
1.) Commits merged to master today are destined for the next minor release,
currently 0.6.0, by default?
2.) Is master always open for merging new code, or are there restrictions
before or after releases?
3.) How long will support/0.5.x be maintained?
4.) Where is compatibility-breaking code destined for a future major
release stored? Is it visible anywhere?
5.) A critical data/security bug found after 1.0 would eligible to be
backported only to the last minor release in the 0.x line, or to all minor
releases in the 0.x line?
On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt <jo...@gmail.com> wrote:
> Given the discussion has stalled i'd like to turn it more toward a
> proposal as we're at a point now where we need to start executing some
> of these approaches. We're actually already seeing it take form in
> the support/0.5.x branch and the master branch (which is for 0.6.0 at
> this point).
>
> The proposal then for Git processes based on the other thread [1]
> where we outline a support model:
>
> - 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
>
> [1]
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
>
> Thanks
> Joe
>
> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
> > I don't want to kill this thread. It is good to discuss specific
> > tooling/procedures. But I do want to get some consensus discussion
> > around Tony's original intent (as I read it). So kicked off a
> > discussion back at that level.
> >
> >
> >
> > On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
> >> While I like gitflow, I can't say I like any of the plugins that are
> used.
> >> I have worked on some other projects (unfortunately not open source)
> that
> >> use a gitflow inspired workflow, without ever using a plugin. Nice side
> >> effect is that I believe this got me better at using git, and generally
> we
> >> all got better at managing merge pain.
> >>
> >> On merge problems, I think the reason we're operating the way we are
> now is
> >> to avoid merge mayhem. I think the initial bar for a patch is "can be
> >> merged into master", and we have our friend Travis to make this even
> easier
> >> to know upfront. This greatly simplifies things. If a bugfix is "patch
> >> needs to be able to apply onto the current release in progress, master,
> and
> >> several other versions we're supporting, with possibly drastically
> >> different code", well then things get interesting.
> >>
> >>
> >>
> >> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <
> bimargulies@gmail.com>
> >> wrote:
> >>
> >>> The issue tracker
> >>>
> >>>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> >>> might also prove useful in evaluating it.
> >>>
> >>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> >>> <bi...@gmail.com> wrote:
> >>> > I tried to use the bitbucket gitflow plugin. It worked great, until
> it
> >>> > didn't. It would get into terrible, inexplicable, merge problems. No
> >>> > one seemed to be maintaining it.
> >>> >
> >>> > There's a new offering in this dept:
> >>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >>> >
> >>> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com>
> wrote:
> >>> >> One of the harder things with gitflow is using it in combination
> with
> >>> >> maven. It's ideal that the tags and releases are tracking closely
> with
> >>> the
> >>> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
> >>> version
> >>> >> updated with the git release names.
> >>> >>
> >>> >> Because of the general importance of keeping releases and tags
> >>> synchronized
> >>> >> with the pom version, I think whatever we do, it needs to be
> approached
> >>> >> with tools that are available through maven rather than from git.
> The
> >>> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
> >>> this
> >>> >> synchronization, since it's a git tool, not a maven tool.
> >>> >>
> >>> >> I've been using, with reasonable success, the jgitflow [1] plugin,
> which
> >>> >> does a reasonable job of following the gitflow model for a maven
> >>> project.
> >>> >> I don't recommend this plugin for NIFI, because it insists that the
> >>> master
> >>> >> branch is strictly used for published release tags (as per the
> strict
> >>> >> gitflow workflow). I just mention this, in reference to how some
> >>> plugins
> >>> >> are tackling the gitflow and maven synchronization issue.
> >>> >>
> >>> >> [1] http://jgitflow.bitbucket.org/
> >>> >>
> >>> >>
> >>> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <thadguidry@gmail.com
> >
> >>> wrote:
> >>> >>
> >>> >>> Your on the right track / idea with Git-flow. Your Master become
> >>> primary
> >>> >>> development of next release (with feature branches off of it)..
> while
> >>> you
> >>> >>> continue to have release branches that can have hot fix branches
> off of
> >>> >>> them. (don't use Master as your release branch ! - bad practice !
> )
> >>> >>>
> >>> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
> >>> >>> understand... just scroll it down to gain the understanding. Its
> really
> >>> >>> that easy.
> >>> >>>
> >>> >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>> >>>
> >>> >>> Most large projects have moved into using git-flow ... and tools
> like
> >>> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either
> built
> >>> in or
> >>> >>> plugin available now. If you want to live on the command line,
> then
> >>> that
> >>> >>> is handled easily by the instructions in the above link.
> >>> >>>
> >>> >>> Thad
> >>> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >>> >>>
> >>>
>
Re: [DISCUSS] git branching model
Posted by Joe Witt <jo...@gmail.com>.
Given the discussion has stalled i'd like to turn it more toward a
proposal as we're at a point now where we need to start executing some
of these approaches. We're actually already seeing it take form in
the support/0.5.x branch and the master branch (which is for 0.6.0 at
this point).
The proposal then for Git processes based on the other thread [1]
where we outline a support model:
- 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
[1] http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E
Thanks
Joe
On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt <jo...@gmail.com> wrote:
> I don't want to kill this thread. It is good to discuss specific
> tooling/procedures. But I do want to get some consensus discussion
> around Tony's original intent (as I read it). So kicked off a
> discussion back at that level.
>
>
>
> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
>> While I like gitflow, I can't say I like any of the plugins that are used.
>> I have worked on some other projects (unfortunately not open source) that
>> use a gitflow inspired workflow, without ever using a plugin. Nice side
>> effect is that I believe this got me better at using git, and generally we
>> all got better at managing merge pain.
>>
>> On merge problems, I think the reason we're operating the way we are now is
>> to avoid merge mayhem. I think the initial bar for a patch is "can be
>> merged into master", and we have our friend Travis to make this even easier
>> to know upfront. This greatly simplifies things. If a bugfix is "patch
>> needs to be able to apply onto the current release in progress, master, and
>> several other versions we're supporting, with possibly drastically
>> different code", well then things get interesting.
>>
>>
>>
>> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>
>>> The issue tracker
>>>
>>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>>> might also prove useful in evaluating it.
>>>
>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>>> <bi...@gmail.com> wrote:
>>> > I tried to use the bitbucket gitflow plugin. It worked great, until it
>>> > didn't. It would get into terrible, inexplicable, merge problems. No
>>> > one seemed to be maintaining it.
>>> >
>>> > There's a new offering in this dept:
>>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>>> >
>>> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com> wrote:
>>> >> One of the harder things with gitflow is using it in combination with
>>> >> maven. It's ideal that the tags and releases are tracking closely with
>>> the
>>> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
>>> version
>>> >> updated with the git release names.
>>> >>
>>> >> Because of the general importance of keeping releases and tags
>>> synchronized
>>> >> with the pom version, I think whatever we do, it needs to be approached
>>> >> with tools that are available through maven rather than from git. The
>>> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
>>> this
>>> >> synchronization, since it's a git tool, not a maven tool.
>>> >>
>>> >> I've been using, with reasonable success, the jgitflow [1] plugin, which
>>> >> does a reasonable job of following the gitflow model for a maven
>>> project.
>>> >> I don't recommend this plugin for NIFI, because it insists that the
>>> master
>>> >> branch is strictly used for published release tags (as per the strict
>>> >> gitflow workflow). I just mention this, in reference to how some
>>> plugins
>>> >> are tackling the gitflow and maven synchronization issue.
>>> >>
>>> >> [1] http://jgitflow.bitbucket.org/
>>> >>
>>> >>
>>> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com>
>>> wrote:
>>> >>
>>> >>> Your on the right track / idea with Git-flow. Your Master become
>>> primary
>>> >>> development of next release (with feature branches off of it).. while
>>> you
>>> >>> continue to have release branches that can have hot fix branches off of
>>> >>> them. (don't use Master as your release branch ! - bad practice ! )
>>> >>>
>>> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
>>> >>> understand... just scroll it down to gain the understanding. Its really
>>> >>> that easy.
>>> >>>
>>> >>> http://danielkummer.github.io/git-flow-cheatsheet/
>>> >>>
>>> >>> Most large projects have moved into using git-flow ... and tools like
>>> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built
>>> in or
>>> >>> plugin available now. If you want to live on the command line, then
>>> that
>>> >>> is handled easily by the instructions in the above link.
>>> >>>
>>> >>> Thad
>>> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>> >>>
>>>
Re: [DISCUSS] git branching model
Posted by Joe Witt <jo...@gmail.com>.
I don't want to kill this thread. It is good to discuss specific
tooling/procedures. But I do want to get some consensus discussion
around Tony's original intent (as I read it). So kicked off a
discussion back at that level.
On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc <tr...@gmail.com> wrote:
> While I like gitflow, I can't say I like any of the plugins that are used.
> I have worked on some other projects (unfortunately not open source) that
> use a gitflow inspired workflow, without ever using a plugin. Nice side
> effect is that I believe this got me better at using git, and generally we
> all got better at managing merge pain.
>
> On merge problems, I think the reason we're operating the way we are now is
> to avoid merge mayhem. I think the initial bar for a patch is "can be
> merged into master", and we have our friend Travis to make this even easier
> to know upfront. This greatly simplifies things. If a bugfix is "patch
> needs to be able to apply onto the current release in progress, master, and
> several other versions we're supporting, with possibly drastically
> different code", well then things get interesting.
>
>
>
> On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>
>> The issue tracker
>>
>> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
>> might also prove useful in evaluating it.
>>
>> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
>> <bi...@gmail.com> wrote:
>> > I tried to use the bitbucket gitflow plugin. It worked great, until it
>> > didn't. It would get into terrible, inexplicable, merge problems. No
>> > one seemed to be maintaining it.
>> >
>> > There's a new offering in this dept:
>> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>> >
>> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com> wrote:
>> >> One of the harder things with gitflow is using it in combination with
>> >> maven. It's ideal that the tags and releases are tracking closely with
>> the
>> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
>> version
>> >> updated with the git release names.
>> >>
>> >> Because of the general importance of keeping releases and tags
>> synchronized
>> >> with the pom version, I think whatever we do, it needs to be approached
>> >> with tools that are available through maven rather than from git. The
>> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
>> this
>> >> synchronization, since it's a git tool, not a maven tool.
>> >>
>> >> I've been using, with reasonable success, the jgitflow [1] plugin, which
>> >> does a reasonable job of following the gitflow model for a maven
>> project.
>> >> I don't recommend this plugin for NIFI, because it insists that the
>> master
>> >> branch is strictly used for published release tags (as per the strict
>> >> gitflow workflow). I just mention this, in reference to how some
>> plugins
>> >> are tackling the gitflow and maven synchronization issue.
>> >>
>> >> [1] http://jgitflow.bitbucket.org/
>> >>
>> >>
>> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com>
>> wrote:
>> >>
>> >>> Your on the right track / idea with Git-flow. Your Master become
>> primary
>> >>> development of next release (with feature branches off of it).. while
>> you
>> >>> continue to have release branches that can have hot fix branches off of
>> >>> them. (don't use Master as your release branch ! - bad practice ! )
>> >>>
>> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
>> >>> understand... just scroll it down to gain the understanding. Its really
>> >>> that easy.
>> >>>
>> >>> http://danielkummer.github.io/git-flow-cheatsheet/
>> >>>
>> >>> Most large projects have moved into using git-flow ... and tools like
>> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built
>> in or
>> >>> plugin available now. If you want to live on the command line, then
>> that
>> >>> is handled easily by the instructions in the above link.
>> >>>
>> >>> Thad
>> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>> >>>
>>
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
While I like gitflow, I can't say I like any of the plugins that are used.
I have worked on some other projects (unfortunately not open source) that
use a gitflow inspired workflow, without ever using a plugin. Nice side
effect is that I believe this got me better at using git, and generally we
all got better at managing merge pain.
On merge problems, I think the reason we're operating the way we are now is
to avoid merge mayhem. I think the initial bar for a patch is "can be
merged into master", and we have our friend Travis to make this even easier
to know upfront. This greatly simplifies things. If a bugfix is "patch
needs to be able to apply onto the current release in progress, master, and
several other versions we're supporting, with possibly drastically
different code", well then things get interesting.
On Mon, Feb 15, 2016 at 12:04 PM, Benson Margulies <bi...@gmail.com>
wrote:
> The issue tracker
>
> https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
> might also prove useful in evaluating it.
>
> On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
> <bi...@gmail.com> wrote:
> > I tried to use the bitbucket gitflow plugin. It worked great, until it
> > didn't. It would get into terrible, inexplicable, merge problems. No
> > one seemed to be maintaining it.
> >
> > There's a new offering in this dept:
> > https://github.com/egineering-llc/gitflow-helper-maven-plugin.
> >
> > On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com> wrote:
> >> One of the harder things with gitflow is using it in combination with
> >> maven. It's ideal that the tags and releases are tracking closely with
> the
> >> maven pom.xml version. gitflow, on its own, doesn't keep the pom
> version
> >> updated with the git release names.
> >>
> >> Because of the general importance of keeping releases and tags
> synchronized
> >> with the pom version, I think whatever we do, it needs to be approached
> >> with tools that are available through maven rather than from git. The
> >> git-flow plugin (referenced by Thad) doesn't directly help deal with
> this
> >> synchronization, since it's a git tool, not a maven tool.
> >>
> >> I've been using, with reasonable success, the jgitflow [1] plugin, which
> >> does a reasonable job of following the gitflow model for a maven
> project.
> >> I don't recommend this plugin for NIFI, because it insists that the
> master
> >> branch is strictly used for published release tags (as per the strict
> >> gitflow workflow). I just mention this, in reference to how some
> plugins
> >> are tackling the gitflow and maven synchronization issue.
> >>
> >> [1] http://jgitflow.bitbucket.org/
> >>
> >>
> >> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com>
> wrote:
> >>
> >>> Your on the right track / idea with Git-flow. Your Master become
> primary
> >>> development of next release (with feature branches off of it).. while
> you
> >>> continue to have release branches that can have hot fix branches off of
> >>> them. (don't use Master as your release branch ! - bad practice ! )
> >>>
> >>> Here is the Git-flow cheat sheet to make it easy for everyone to
> >>> understand... just scroll it down to gain the understanding. Its really
> >>> that easy.
> >>>
> >>> http://danielkummer.github.io/git-flow-cheatsheet/
> >>>
> >>> Most large projects have moved into using git-flow ... and tools like
> >>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built
> in or
> >>> plugin available now. If you want to live on the command line, then
> that
> >>> is handled easily by the instructions in the above link.
> >>>
> >>> Thad
> >>> +ThadGuidry <https://www.google.com/+ThadGuidry>
> >>>
>
Re: [DISCUSS] git branching model
Posted by Benson Margulies <bi...@gmail.com>.
The issue tracker
https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues
might also prove useful in evaluating it.
On Mon, Feb 15, 2016 at 12:03 PM, Benson Margulies
<bi...@gmail.com> wrote:
> I tried to use the bitbucket gitflow plugin. It worked great, until it
> didn't. It would get into terrible, inexplicable, merge problems. No
> one seemed to be maintaining it.
>
> There's a new offering in this dept:
> https://github.com/egineering-llc/gitflow-helper-maven-plugin.
>
> On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com> wrote:
>> One of the harder things with gitflow is using it in combination with
>> maven. It's ideal that the tags and releases are tracking closely with the
>> maven pom.xml version. gitflow, on its own, doesn't keep the pom version
>> updated with the git release names.
>>
>> Because of the general importance of keeping releases and tags synchronized
>> with the pom version, I think whatever we do, it needs to be approached
>> with tools that are available through maven rather than from git. The
>> git-flow plugin (referenced by Thad) doesn't directly help deal with this
>> synchronization, since it's a git tool, not a maven tool.
>>
>> I've been using, with reasonable success, the jgitflow [1] plugin, which
>> does a reasonable job of following the gitflow model for a maven project.
>> I don't recommend this plugin for NIFI, because it insists that the master
>> branch is strictly used for published release tags (as per the strict
>> gitflow workflow). I just mention this, in reference to how some plugins
>> are tackling the gitflow and maven synchronization issue.
>>
>> [1] http://jgitflow.bitbucket.org/
>>
>>
>> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com> wrote:
>>
>>> Your on the right track / idea with Git-flow. Your Master become primary
>>> development of next release (with feature branches off of it).. while you
>>> continue to have release branches that can have hot fix branches off of
>>> them. (don't use Master as your release branch ! - bad practice ! )
>>>
>>> Here is the Git-flow cheat sheet to make it easy for everyone to
>>> understand... just scroll it down to gain the understanding. Its really
>>> that easy.
>>>
>>> http://danielkummer.github.io/git-flow-cheatsheet/
>>>
>>> Most large projects have moved into using git-flow ... and tools like
>>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built in or
>>> plugin available now. If you want to live on the command line, then that
>>> is handled easily by the instructions in the above link.
>>>
>>> Thad
>>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>>
Re: [DISCUSS] git branching model
Posted by Benson Margulies <bi...@gmail.com>.
I tried to use the bitbucket gitflow plugin. It worked great, until it
didn't. It would get into terrible, inexplicable, merge problems. No
one seemed to be maintaining it.
There's a new offering in this dept:
https://github.com/egineering-llc/gitflow-helper-maven-plugin.
On Mon, Feb 15, 2016 at 11:41 AM, Adam Taft <ad...@adamtaft.com> wrote:
> One of the harder things with gitflow is using it in combination with
> maven. It's ideal that the tags and releases are tracking closely with the
> maven pom.xml version. gitflow, on its own, doesn't keep the pom version
> updated with the git release names.
>
> Because of the general importance of keeping releases and tags synchronized
> with the pom version, I think whatever we do, it needs to be approached
> with tools that are available through maven rather than from git. The
> git-flow plugin (referenced by Thad) doesn't directly help deal with this
> synchronization, since it's a git tool, not a maven tool.
>
> I've been using, with reasonable success, the jgitflow [1] plugin, which
> does a reasonable job of following the gitflow model for a maven project.
> I don't recommend this plugin for NIFI, because it insists that the master
> branch is strictly used for published release tags (as per the strict
> gitflow workflow). I just mention this, in reference to how some plugins
> are tackling the gitflow and maven synchronization issue.
>
> [1] http://jgitflow.bitbucket.org/
>
>
> On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com> wrote:
>
>> Your on the right track / idea with Git-flow. Your Master become primary
>> development of next release (with feature branches off of it).. while you
>> continue to have release branches that can have hot fix branches off of
>> them. (don't use Master as your release branch ! - bad practice ! )
>>
>> Here is the Git-flow cheat sheet to make it easy for everyone to
>> understand... just scroll it down to gain the understanding. Its really
>> that easy.
>>
>> http://danielkummer.github.io/git-flow-cheatsheet/
>>
>> Most large projects have moved into using git-flow ... and tools like
>> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built in or
>> plugin available now. If you want to live on the command line, then that
>> is handled easily by the instructions in the above link.
>>
>> Thad
>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>
Re: [DISCUSS] git branching model
Posted by Adam Taft <ad...@adamtaft.com>.
One of the harder things with gitflow is using it in combination with
maven. It's ideal that the tags and releases are tracking closely with the
maven pom.xml version. gitflow, on its own, doesn't keep the pom version
updated with the git release names.
Because of the general importance of keeping releases and tags synchronized
with the pom version, I think whatever we do, it needs to be approached
with tools that are available through maven rather than from git. The
git-flow plugin (referenced by Thad) doesn't directly help deal with this
synchronization, since it's a git tool, not a maven tool.
I've been using, with reasonable success, the jgitflow [1] plugin, which
does a reasonable job of following the gitflow model for a maven project.
I don't recommend this plugin for NIFI, because it insists that the master
branch is strictly used for published release tags (as per the strict
gitflow workflow). I just mention this, in reference to how some plugins
are tackling the gitflow and maven synchronization issue.
[1] http://jgitflow.bitbucket.org/
On Sun, Feb 14, 2016 at 10:48 PM, Thad Guidry <th...@gmail.com> wrote:
> Your on the right track / idea with Git-flow. Your Master become primary
> development of next release (with feature branches off of it).. while you
> continue to have release branches that can have hot fix branches off of
> them. (don't use Master as your release branch ! - bad practice ! )
>
> Here is the Git-flow cheat sheet to make it easy for everyone to
> understand... just scroll it down to gain the understanding. Its really
> that easy.
>
> http://danielkummer.github.io/git-flow-cheatsheet/
>
> Most large projects have moved into using git-flow ... and tools like
> Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built in or
> plugin available now. If you want to live on the command line, then that
> is handled easily by the instructions in the above link.
>
> Thad
> +ThadGuidry <https://www.google.com/+ThadGuidry>
>
Re: [DISCUSS] git branching model
Posted by Thad Guidry <th...@gmail.com>.
Your on the right track / idea with Git-flow. Your Master become primary
development of next release (with feature branches off of it).. while you
continue to have release branches that can have hot fix branches off of
them. (don't use Master as your release branch ! - bad practice ! )
Here is the Git-flow cheat sheet to make it easy for everyone to
understand... just scroll it down to gain the understanding. Its really
that easy.
http://danielkummer.github.io/git-flow-cheatsheet/
Most large projects have moved into using git-flow ... and tools like
Eclipse Mars, IntelliJ, Sourcetree, etc...have Git-flow either built in or
plugin available now. If you want to live on the command line, then that
is handled easily by the instructions in the above link.
Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Re: [DISCUSS] git branching model
Posted by Tony Kurc <tr...@gmail.com>.
Mat, I'm not entirely sure that a release branch would have helped. As I
mentioned, we sort of used master as the release branch. I just built off
of the wrong commit, which could happen even with a release branch. That
being said, I think it is a good idea (I think it would have helped with
the 0.4.1 release).
I definitely believe we need to have the intended commit to start a release
from as part of the verification. I used some bash with environment
variables as input for doing the RC (for the RC number, the release ticket,
and nifi version). The branch point for the RC would be a delightful one of
those variables
On Sat, Feb 13, 2016 at 12:35 PM, Matt Gilman <ma...@gmail.com>
wrote:
> A couple thoughts...
>
> Push release branches. This would help avoid the confusion we had with the
> 0.5.0 release. It would be clear that bug fixes being made for the current
> release would need to be pushed to both master and the release branch. It
> would also allow master to continue receiving commits that will not be
> incorporated into the current release. Using branches (in addition to tags)
> would make it easier if multiple folks are committing bug fixes as was the
> case with 0.5.0. It may even make sense to keep the release branch around
> for awhile (maybe X subsequent releases). This would also provide a
> convenient place to branch from if we needed a quick bugfix release like we
> did in 0.4.1.
>
> Moving forward when we start working some 1.X features I would like to see
> essentially two masters (though we can name them whatever we want).
> Continue with the same model (RTC) as we do currently but pushing commits
> to either the 0.X master, the 1.X master, or both. We would continue to
> support both master branches until we've stopped support for the 0.X
> baseline whenever we decide that will be.
>
> Matt
>
> On Sat, Feb 13, 2016 at 10:16 AM, Tony Kurc <tk...@apache.org> wrote:
>
> > All,
> > I wanted to renew a discussion about our git branching model. We posted a
> > proposed roadmap a while back [1]. For those familiar, there are some
> > pretty big features that are going to be awesome, but at the same time,
> may
> > make having an overlap of supported major versions likely more desirable
> > due to the magnitude of changes on the way. It seems as though our
> current
> > de facto branching model may make that challenging. My observation is
> that
> > although we discussed doing something like gitflow [2], we seem to "just
> be
> > really careful around with master around a release" and move on to the
> next
> > release (and do some things I think are ugly if we need a quick bugfix
> > release like 0.4.1).
> >
> > Some things I think we're happy with now. 'master' being our eternal
> > branch, and comfortable with feature branches named after their jiras.
> Its
> > pretty evident from looking at contributors' forks on github when doing
> PR
> > reviews that it is a pretty well understood convention.
> >
> > I think we can find a way to keep the above going and still support
> > multiple versions being developed at once.
> >
> > I have some ideas, but in order to avoid polluting the discussion with
> what
> > is in my head, I figured I'd hold off on suggestions and let people mull
> it
> > over.
> >
> > Specific questions:
> > How do we;
> > - have a 1.X in development (many months, many features, and we want
> people
> > trying early)
> > - have 0.X continue to live while that is happening for people who need
> it
> > for production
> > - have some features target both 0.X and 1.X
> > - have relevant bugfixes hit both 0.X and 1.X
> > - avoid the pain of the 0.4.1 release?
> >
> > What will master look like while we're doing this?
> > What will we call our branches?
> > Who would integrate patches and PRs into multiple versions? Reviewer?
> > Submitter? Or would this be another ticket?
> > What project does this well and could be a model?
> > What questions did I forget to ask?
> > Should we decide to only have one version "supported" at a time to avoid
> > this?
> >
> > 1.
> >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
> > 2. http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Thank you for your input
> >
> > Tony
> >
>
Re: [DISCUSS] git branching model
Posted by Matt Gilman <ma...@gmail.com>.
A couple thoughts...
Push release branches. This would help avoid the confusion we had with the
0.5.0 release. It would be clear that bug fixes being made for the current
release would need to be pushed to both master and the release branch. It
would also allow master to continue receiving commits that will not be
incorporated into the current release. Using branches (in addition to tags)
would make it easier if multiple folks are committing bug fixes as was the
case with 0.5.0. It may even make sense to keep the release branch around
for awhile (maybe X subsequent releases). This would also provide a
convenient place to branch from if we needed a quick bugfix release like we
did in 0.4.1.
Moving forward when we start working some 1.X features I would like to see
essentially two masters (though we can name them whatever we want).
Continue with the same model (RTC) as we do currently but pushing commits
to either the 0.X master, the 1.X master, or both. We would continue to
support both master branches until we've stopped support for the 0.X
baseline whenever we decide that will be.
Matt
On Sat, Feb 13, 2016 at 10:16 AM, Tony Kurc <tk...@apache.org> wrote:
> All,
> I wanted to renew a discussion about our git branching model. We posted a
> proposed roadmap a while back [1]. For those familiar, there are some
> pretty big features that are going to be awesome, but at the same time, may
> make having an overlap of supported major versions likely more desirable
> due to the magnitude of changes on the way. It seems as though our current
> de facto branching model may make that challenging. My observation is that
> although we discussed doing something like gitflow [2], we seem to "just be
> really careful around with master around a release" and move on to the next
> release (and do some things I think are ugly if we need a quick bugfix
> release like 0.4.1).
>
> Some things I think we're happy with now. 'master' being our eternal
> branch, and comfortable with feature branches named after their jiras. Its
> pretty evident from looking at contributors' forks on github when doing PR
> reviews that it is a pretty well understood convention.
>
> I think we can find a way to keep the above going and still support
> multiple versions being developed at once.
>
> I have some ideas, but in order to avoid polluting the discussion with what
> is in my head, I figured I'd hold off on suggestions and let people mull it
> over.
>
> Specific questions:
> How do we;
> - have a 1.X in development (many months, many features, and we want people
> trying early)
> - have 0.X continue to live while that is happening for people who need it
> for production
> - have some features target both 0.X and 1.X
> - have relevant bugfixes hit both 0.X and 1.X
> - avoid the pain of the 0.4.1 release?
>
> What will master look like while we're doing this?
> What will we call our branches?
> Who would integrate patches and PRs into multiple versions? Reviewer?
> Submitter? Or would this be another ticket?
> What project does this well and could be a model?
> What questions did I forget to ask?
> Should we decide to only have one version "supported" at a time to avoid
> this?
>
> 1.
>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
> 2. http://nvie.com/posts/a-successful-git-branching-model/
>
> Thank you for your input
>
> Tony
>