Adding on to what Matt has said below I'll pose three questions, and offer some
ideas for solutions. Please comment.
1) What would we do if 0.0.2 RC1 "failed", and we needed to do a 0.0.2 RC2?
1a) have a long living release branch called "0.0.X" or something like that
where 0.0.2 RC 1 would be made from(NIFI-402-RC1 is what I am talking about, it
just is currently labeled in a way that makes you think its for RC1 only...).
If an RC2 is needed, changes happen in this branch, and RC2 can be released
from this branch. Naming it "0.0.X" should give other devs a clear idea as to
where to contribute to if they are helping with fixes for the release.
2) What would we do if 0.0.2 RC1 succeeds, is released, and we discover a bug
and want to call it 0.0.3
2a) reuse the long living branch from 1a. This is where changes to support
0.0.3 would go, and the 0.0.3 release would happen. Again naming it "0.0.X"
should give people a good idea where to contribute.
2b) create a new branch off of the 0.0.1 tag, make the fixes there, and do
the release from there.
3) Will contributing new features to develop affect our abilities to do 1 or 2?
3a) I do not think so, provided there is a separate branch for the release
Personally I would propose that at the time that all tickets are closed for a
major or feature release(0.1.0, 0.2.0, 0.3.0, 1.0.0) someone make a branch
called (0.1.X, 0.2.X, 0.3.X, 1.0.X). This branch will be used to make changes
to support the release, and contain any minor bug fix changes(0.1.1, 0.1.2,
0.1.3, 1.0.1). Then people working on the release and bug fixes for it have a
place to do that, while people working on features for the next release can
continue to do that back on 'develop'
Dan Bress
Software Engineer
ONYX Consulting Services
________________________________________
From: Matt Gilman <[email protected]>
Sent: Thursday, March 12, 2015 9:21 AM
To: [email protected]
Subject: Re: Release branch workflow business
My primary concerns are:
1) Holding up work on develop while waiting for the release to be finalized
(voted, etc). It's not clear to me if the current approach supports this if
we need to create a RC2.
2) Users trying to get a specific version of Apache NiFi. If the branches
were named according to their release version, it's very easy for them to
identify the branch they care about.
I thought when we were setting everything up initially we decided to
practice gitflow [1]. I don't think we've done this as describe. I'm not
suggesting that we have to, there are certainly modified approaches that
can scratch the itch. Just wanted to make sure the larger concerns are
handled.
[1]
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
On Thu, Mar 12, 2015 at 9:10 AM, Joe Witt <[email protected]> wrote:
> The release process does generate a tag that is named after the version.
> Does that not quite scratch the itch?
>
> Thanks
> Joe
> On Mar 12, 2015 8:07 AM, "Dan Bress" <[email protected]> wrote:
>
> > Matt,
> > I back the idea of of naming the release branch by the name of the
> > major/minor numbers(in this case 0.0). Mainly so if after 0.0.2 gets
> > released and we need to fix a bug and call it 0.0.3, we could reuse the
> 0.0
> > release branch and not have to create a new one.
> >
> > Dan Bress
> > Software Engineer
> > ONYX Consulting Services
> >
> > ________________________________________
> > From: Matt Gilman <[email protected]>
> > Sent: Thursday, March 12, 2015 8:39 AM
> > To: [email protected]
> > Subject: Re: Release branch workflow business
> >
> > Just wanted to confirm what was done when the RC was cut for 0.0.2. It
> > appears that a branch was created for the release (NIFI-402-RC1). Does
> this
> > mean it's ok for Dan and others to commit to develop for features going
> > into 0.1.0 (or whatever our next release after 0.0.2 will be)?
> >
> > Any issues discovered with the RC for 0.0.2 should be addressed in that
> > branch and develop. Pretty sure this was the agreed upon workflow we
> > discussed initially. If this is accurate can I request naming the release
> > branches according to their version going forward? This may help avoid
> some
> > confusion.
> >
> > If my assumptions are not accurate or there's some aspect of the release
> > process that changes this please let me know.
> >
> > Matt
> >
> > On Sun, Mar 8, 2015 at 11:35 AM, Joe Witt <[email protected]> wrote:
> >
> > > Dan
> > >
> > > For my own part I should be able to start the party this week. Seemed
> > non
> > > controversial to kick it off so you're right I think.
> > >
> > > As for the branch yes it does work like you suggest. Will take a
> closer
> > > look tomorrow.
> > >
> > > I will check the status of tickets as well. We really need some sort
> of
> > > rough roadmap up.
> > >
> > > Thanks
> > > Joe
> > > On Mar 8, 2015 10:14 AM, "Dan Bress" <[email protected]> wrote:
> > >
> > > > Hey Joe and all,
> > > >
> > > > What is your plan/process for creating release branches to do the
> > > 0.0.2
> > > > release(and future releases) in? I was under the impression that you
> > > would
> > > > want to do this as soon as all of the 0.0.2 tickets are closed(which
> I
> > > > thought I heard has happened). If all the 0.0.2 tickets are
> complete,
> > > I'd
> > > > recommend making a branch to do the release in so that we can begin
> > > > integrating any of the 0.1.0 features in develop. I'm recommending
> > from
> > > a
> > > > somewhat selfish standpoint so that the component documentation
> > feature I
> > > > worked on can be integrated before more changes happen in develop
> that
> > > > might cause the merge to be problematic.
> > > >
> > > >
> > > > Let me know what you think,
> > > >
> > > >
> > > > Dan Bress
> > > > Software Engineer
> > > > ONYX Consulting Services
> > > >
> > >
> >
>
