Release branch workflow business

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Release branch workflow business

Dan Bress
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
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Joe Witt
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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Matt Gilman
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 <[hidden email]> 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" <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Dan Bress
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 <[hidden email]>
Sent: Thursday, March 12, 2015 8:39 AM
To: [hidden email]
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 <[hidden email]> 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" <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Joe Witt
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" <[hidden email]> 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 <[hidden email]>
> Sent: Thursday, March 12, 2015 8:39 AM
> To: [hidden email]
> 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 <[hidden email]> 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" <[hidden email]> 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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Matt Gilman
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> > Sent: Thursday, March 12, 2015 8:39 AM
> > To: [hidden email]
> > 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 <[hidden email]> 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" <[hidden email]> 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
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Dan Bress
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 <[hidden email]>
Sent: Thursday, March 12, 2015 9:21 AM
To: [hidden email]
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> > Sent: Thursday, March 12, 2015 8:39 AM
> > To: [hidden email]
> > 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 <[hidden email]> 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" <[hidden email]> 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
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Brandon DeVries
All,

     I pretty much agree with Dan.  It seems as though we've stumbled into
a pretty common opinion about git-flow, "that it's more complicated than...
most developers and development teams actually require" [1].  That comes
from a page describing "GitHub Flow" which is a simpler workflow, although
somewhat centered around the ability to continuously deploy to production.

     For people (like us) who do need some sort of release structure,
"GitLab Flow" [2] adds a bit to "GitHub Flow".  Actually, GitLab Flow seems
to be  GitHub Flow <minus> continuous deployment <plus> branches for
releases (or production environments, but that's less applicable to us).
The beginning of [2] has some good background, but the section "Release
branches with GitLab flow" is particularly relevant to this conversation,
as it is pretty close to what Dan was describing:

...each branch contains a minor version (2-3-stable, 2-4-stable, etc.). The
stable branch uses master as a starting point and is created as late as
possible. By branching as late as possible you minimize the time you have
to apply bugfixes to multiple branches. After a release branch is
announced, only serious bug fixes are included in the release branch. If
possible these bug fixes are first merged into master and then
cherry-picked into the release branch. [2]

     Like git-flow, development is still done in feature branches.  However
there are no "develop" or "hotfix" branches. "Master" should always be in a
deployable state.  That's basically it.  There's still the mechanics of
pull requests and RTC and all of that, but the complexity of the flow is
reduced.  Does this (GitLab Flow) seem like a model that people could work
with?

Brandon

[1]
http://scottchacon.com/2011/08/31/github-flow.html

[2]
https://about.gitlab.com/2014/09/29/gitlab-flow/

On Fri, Mar 13, 2015 at 9:55 AM Dan Bress <[hidden email]> wrote:

> 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 <[hidden email]>
> Sent: Thursday, March 12, 2015 9:21 AM
> To: [hidden email]
> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> > > Sent: Thursday, March 12, 2015 8:39 AM
> > > To: [hidden email]
> > > 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 <[hidden email]> 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" <[hidden email]>
> 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
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Joe Witt
Hello

I am a +1 on the statements/concerns.  Can you please edit the
release-guide on our site to provide more precision about how this
should flow and why (so people can safely continue building on dev)?

We need to make this information/process well understood.  In addition
to documenting our agreements it is also important we fully document
the dance that is the release process so folks can comfortably pick up
the RM ball and run with it.

Thanks
Joe

On Fri, Mar 13, 2015 at 5:02 PM, Brandon DeVries <[hidden email]> wrote:

> All,
>
>      I pretty much agree with Dan.  It seems as though we've stumbled into
> a pretty common opinion about git-flow, "that it's more complicated than...
> most developers and development teams actually require" [1].  That comes
> from a page describing "GitHub Flow" which is a simpler workflow, although
> somewhat centered around the ability to continuously deploy to production.
>
>      For people (like us) who do need some sort of release structure,
> "GitLab Flow" [2] adds a bit to "GitHub Flow".  Actually, GitLab Flow seems
> to be  GitHub Flow <minus> continuous deployment <plus> branches for
> releases (or production environments, but that's less applicable to us).
> The beginning of [2] has some good background, but the section "Release
> branches with GitLab flow" is particularly relevant to this conversation,
> as it is pretty close to what Dan was describing:
>
> ...each branch contains a minor version (2-3-stable, 2-4-stable, etc.). The
> stable branch uses master as a starting point and is created as late as
> possible. By branching as late as possible you minimize the time you have
> to apply bugfixes to multiple branches. After a release branch is
> announced, only serious bug fixes are included in the release branch. If
> possible these bug fixes are first merged into master and then
> cherry-picked into the release branch. [2]
>
>      Like git-flow, development is still done in feature branches.  However
> there are no "develop" or "hotfix" branches. "Master" should always be in a
> deployable state.  That's basically it.  There's still the mechanics of
> pull requests and RTC and all of that, but the complexity of the flow is
> reduced.  Does this (GitLab Flow) seem like a model that people could work
> with?
>
> Brandon
>
> [1]
> http://scottchacon.com/2011/08/31/github-flow.html
>
> [2]
> https://about.gitlab.com/2014/09/29/gitlab-flow/
>
> On Fri, Mar 13, 2015 at 9:55 AM Dan Bress <[hidden email]> wrote:
>
>> 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 <[hidden email]>
>> Sent: Thursday, March 12, 2015 9:21 AM
>> To: [hidden email]
>> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>> > > Sent: Thursday, March 12, 2015 8:39 AM
>> > > To: [hidden email]
>> > > 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 <[hidden email]> 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" <[hidden email]>
>> 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
>> > > > >
>> > > >
>> > >
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: Release branch workflow business

Brandon DeVries
In reply to this post by Dan Bress
Joe,

Sure,  I'll make the changes.

Brandon

On Mon, Mar 16, 2015, 11:26 AM Joe Witt <[hidden email]> wrote:

> Hello
>
> I am a +1 on the statements/concerns.  Can you please edit the
> release-guide on our site to provide more precision about how this
> should flow and why (so people can safely continue building on dev)?
>
> We need to make this information/process well understood.  In addition
> to documenting our agreements it is also important we fully document
> the dance that is the release process so folks can comfortably pick up
> the RM ball and run with it.
>
> Thanks
> Joe
>
> On Fri, Mar 13, 2015 at 5:02 PM, Brandon DeVries <[hidden email]> wrote:
> > All,
> >
> >      I pretty much agree with Dan.  It seems as though we've stumbled
> into
> > a pretty common opinion about git-flow, "that it's more complicated
> than...
> > most developers and development teams actually require" [1].  That comes
> > from a page describing "GitHub Flow" which is a simpler workflow,
> although
> > somewhat centered around the ability to continuously deploy to
> production.
> >
> >      For people (like us) who do need some sort of release structure,
> > "GitLab Flow" [2] adds a bit to "GitHub Flow".  Actually, GitLab Flow
> seems
> > to be  GitHub Flow <minus> continuous deployment <plus> branches for
> > releases (or production environments, but that's less applicable to us).
> > The beginning of [2] has some good background, but the section "Release
> > branches with GitLab flow" is particularly relevant to this conversation,
> > as it is pretty close to what Dan was describing:
> >
> > ...each branch contains a minor version (2-3-stable, 2-4-stable, etc.).
> The
> > stable branch uses master as a starting point and is created as late as
> > possible. By branching as late as possible you minimize the time you have
> > to apply bugfixes to multiple branches. After a release branch is
> > announced, only serious bug fixes are included in the release branch. If
> > possible these bug fixes are first merged into master and then
> > cherry-picked into the release branch. [2]
> >
> >      Like git-flow, development is still done in feature branches.
> However
> > there are no "develop" or "hotfix" branches. "Master" should always be
> in a
> > deployable state.  That's basically it.  There's still the mechanics of
> > pull requests and RTC and all of that, but the complexity of the flow is
> > reduced.  Does this (GitLab Flow) seem like a model that people could
> work
> > with?
> >
> > Brandon
> >
> > [1]
> > http://scottchacon.com/2011/08/31/github-flow.html
> >
> > [2]
> > https://about.gitlab.com/2014/09/29/gitlab-flow/
> >
> > On Fri, Mar 13, 2015 at 9:55 AM Dan Bress <[hidden email]>
> wrote:
> >
> >> 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 <[hidden email]>
> >> Sent: Thursday, March 12, 2015 9:21 AM
> >> To: [hidden email]
> >> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
> >> > > Sent: Thursday, March 12, 2015 8:39 AM
> >> > > To: [hidden email]
> >> > > 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 <[hidden email]>
> 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" <[hidden email]>
> >> 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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>