nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Gilman <matt.c.gil...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Sat, 13 Feb 2016 17:35:08 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message