nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Kurc <trk...@gmail.com>
Subject Re: [DISCUSS] git branching model
Date Sun, 14 Feb 2016 14:23:25 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message