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 <[email protected]> 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 <[email protected]> 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 > > >
