nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Sat, 13 Feb 2016 19:39:32 GMT
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 <matt.c.gilman@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 <tkurc@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
>>

Mime
View raw message