Joe, Sure, I'll make the changes.
Brandon On Mon, Mar 16, 2015, 11:26 AM Joe Witt <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[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 > >> > > > > > >> > > > > >> > > > >> > > >> >
