Thank You Adam. I think I get it now. I'll favor A over Alt 1 by a little bit.
+1 A +1 B Regards Swapnil On 12/4/15, Adam Bordelon <a...@mesosphere.io> wrote: > Swapnil, the two approaches are indeed similar. I think of my proposal as > extracting the core idea from Alt 1. Let me try to explain the differences. > With my Proposal A, we would only need the following long-lived branches: > master - Where to put feature work and everything else. > 0.1.x - Contains 0.1.0, 0.1.1, etc. release candidates, patches, and the > stable release tag. > 0.2.x - Contains 0.2.0, 0.2.1, etc. release candidates, patches, and the > stable release tag. > ... > > With the "nvie" (Alt 1) approach, there are more branches to manage. > develop - Where to put feature work for upcoming releases. > 0.1.0 - A temporary branch cut from 'develop' branch to prepare the 0.1.0 > release. > 0.1.1 - A temporary branch cut from '0.1.0' tag to prepare the 0.1.1 > release. > 0.1.... > 0.2.0 - A temporary branch cut from 'develop' branch to prepare the 0.2.0 > release. > ... > master - Merge each new stable release in as the new HEAD of master. > > The difference in philosophy is that in the "nvie" approach, you check out > master to get the latest stable release, and you check out 'develop' to get > the bleeding edge, latest code. In my proposal, you check out master to get > the latest code; and you check out the numerically largest (non-rc) tag to > get the latest stable release. In either case, the release branches are for > release preparation, except that my approach reuses the same branch across > multiple patch releases. > > Let me know if you need any further clarification between the approaches. > And please vote -1 if you actually oppose Proposal A, in favor of > Alternative 1. Otherwise, we can just go with lazy consensus, and I'll > consider Proposal A accepted on Monday if it's still the majority vote > (among its alternatives). > > > On Thu, Dec 3, 2015 at 10:30 PM, Swapnil Daingade < > swapnil.daing...@gmail.com> wrote: > >> I did not understand the difference between Proposal A and Alt 1 (the way >> Adam described it). >> Seem quite similar to me >> >> +1 A or Alt1 >> +1 B >> >> Regards >> Swapnil >> >> >> On Fri, Dec 4, 2015 at 8:42 AM, Darin Johnson <dbjohnson1...@gmail.com> >> wrote: >> >> > My experience with alt 1 is it takes a lot of discipline or it devolves >> > into develop just being master. I'd be curious how others have found >> > it. >> > On Dec 3, 2015 10:07 PM, "Darin Johnson" <dbjohnson1...@gmail.com> >> wrote: >> > >> > > +1 A, +1 B. >> > > On Dec 3, 2015 7:12 PM, "Sarjeet Singh" <sarjeetsi...@maprtech.com> >> > wrote: >> > > >> > >> +1 for Proposal A -> Alt 1, and +1 for Proposal B. >> > >> >> > >> Should we also maintain 'develop' & 'master' branch as described on >> > >> nvie.com, >> > >> it was easy to read through the branching model, and understand the >> > >> branching flow without any complexity involved? >> > >> >> > >> Btw, Good pro/con list with references. thanks Adam!! >> > >> >> > >> -Sarjeet >> > >> >> > >> On Thu, Dec 3, 2015 at 2:49 PM, Santosh Marella < >> smare...@maprtech.com> >> > >> wrote: >> > >> >> > >> > Yup. >> > >> > >> > >> > +1 for Proposal A -> Alternative 1. >> > >> > +1 for Proposal B >> > >> > >> > >> > Santosh >> > >> > >> > >> > On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman >> > >> <yufeld...@yahoo.com.invalid >> > >> > > >> > >> > wrote: >> > >> > >> > >> > > I fully second Todd. >> > >> > > Thanks,Yuliya >> > >> > > From: Todd Richmond <trichm...@maprtech.com> >> > >> > > To: dev@myriad.incubator.apache.org >> > >> > > Sent: Thursday, December 3, 2015 8:59 AM >> > >> > > Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete >> > Obsolete >> > >> > > Branches >> > >> > > >> > >> > > excellent pro/con list >> > >> > > >> > >> > > +1 for either A or + .5 for Alt 1. A branch is easy to follow >> > >> > > and >> > >> allows >> > >> > > for long term patch support. Each new 0.x.y patch release >> > >> > > becomes >> > the >> > >> > only >> > >> > > “supported” 0.x version but more than one “x” can be supported >> > >> > > simultaneously >> > >> > > >> > >> > > Alt 2 tags work best when you release very often (such as >> > >> > > monthly) >> > to >> > >> > > users who are willing to upgrade and so can quickly deprecate >> > previous >> > >> > > releases. Cherry-picking is more manual effort and possibly >> > >> > > error >> > >> prone >> > >> > as >> > >> > > the committer count grows >> > >> > > >> > >> > > +1 for proposal B. feature branches can usually be done on >> > >> > > private >> > >> forks >> > >> > > instead and should definitely be removed once the feature is >> merged >> > to >> > >> > > develop >> > >> > > >> > >> > > Todd >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > > On Dec 3, 2015, at 12:36 AM, Adam Bordelon >> > >> > > > <a...@mesosphere.io> >> > >> wrote: >> > >> > > > >> > >> > > > Proposal A: Use Release Branches >> > >> > > > I propose that we create a '0.1.x' branch that will contain >> > >> > > > all >> of >> > >> the >> > >> > > > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags >> > >> > > > related >> > to >> > >> > > hotfix >> > >> > > > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 >> > >> > > > can >> > >> > > cherry-pick >> > >> > > > fixes from master directly on top of the 0.1.0 tag in the >> > >> > > > 0.1.x >> > >> branch, >> > >> > > and >> > >> > > > we'll iterate on its rc's in the 0.1.x branch. Development for >> > >> > > > features/fixes for 0.2.0 go into the master branch, and >> > >> > > > whenever >> > >> 0.2.0 >> > >> > is >> > >> > > > feature-complete/ready, we'll cut the new '0.2.x' branch from >> > master >> > >> > and >> > >> > > > tag a 0.2.0-rc1, then cherry pick any necessary fixes from >> master >> > >> into >> > >> > > > 0.2.x, for future release candidates and hotfix releases. >> > >> > > > + Easy to create/review github PRs to merge fixes into release >> > >> > candidates >> > >> > > > and hotfix releases. >> > >> > > > + Release candidates and hotfixes are handled in the >> > >> > > > appropriate >> > >> > release >> > >> > > > branch, while normal development can continue in master. >> > >> > > > + Minimal additional branches/commands required; no need for >> > >> ephemeral >> > >> > > > branches for each release (candidate). >> > >> > > > >> > >> > > > Alternative 1: Follow >> > >> > > > >> > >> > >> > >> >> > http://nvie.com/posts/a-successful-git-branching-model/#release-branches >> > >> > > > My proposal is similar to the model described by nvie except >> that >> > we >> > >> > use >> > >> > > > the myriad 'master' branch for what he calls the 'develop' >> branch, >> > >> and >> > >> > we >> > >> > > > use our 0.1.x,0.2.x release branches as longer-lived branches >> for >> > >> > hotfix >> > >> > > > releases. (Note: Feature branches are a separate discussion, >> > >> unrelated >> > >> > to >> > >> > > > release management.) >> > >> > > > + Easy to follow guide. >> > >> > > > + Good separation of concerns/responsibility. >> > >> > > > - Doesn't explain how release candidates are handled. >> > >> > > > - So many branches. >> > >> > > > >> > >> > > > Alternative 2: Use tags for releases, no branches (like Mesos >> > does) >> > >> > > > See the discussion at: >> > >> > > > >> > >> > > >> > >> > >> > >> >> > >> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches >> > >> > > > + No mess of branches in the repo; no merging between >> > >> > > > branches. >> > >> > > > + Since release candidates and releases are cherry-picked and >> > >> tagged, >> > >> > > > normal development can continue on master without >> > >> > > interruption/corruption. >> > >> > > > - Github PRs cannot use a tag (Dealbreaker?). >> > >> > > > http://stackoverflow.com/a/12279290/4056606 >> > >> > > > >> > >> > > > Please let me know your thoughts on release branches. I went >> ahead >> > >> and >> > >> > > > created the '0.1.x' branch from the 0.1.0-rc3 tag so you can >> check >> > >> it >> > >> > out >> > >> > > > and play around, and so you can push 0.2.0 features to master >> > >> without >> > >> > > > worrying about messing up the 0.1.0 release. We can >> > >> > > > cherry-pick >> > any >> > >> > > > rc4/0.1.1 patches out of master, and we can always >> > >> delete/rename/reorg >> > >> > > the >> > >> > > > release branch later if desired. >> > >> > > > >> > >> > > >> > >> > >> > >> >> > >> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > Proposal B: Delete all these obsolete branches from the Apache >> git >> > >> > repo: >> > >> > > > 9/23/15 phase1 (72 behind master) >> > >> > > > 8/12/15 constraints (kensipe) >> > >> > > > 8/12/15 myriadha (kensipe) >> > >> > > > 8/10/15 issue_14 (smarella) >> > >> > > > 7/17/15 executor-only-application (kensipe) >> > >> > > > 6/11/15 multi-project (kensipe) >> > >> > > > 6/11/15 docker-image (kensipe) >> > >> > > > 3/04/15 issue_16 (mohit) >> > >> > > > If nobody speaks up to save any/all of these, I'll delete them >> > next >> > >> > week. >> > >> > > > (Note that most of these still live on in the old github repo, >> if >> > >> you >> > >> > > look >> > >> > > > closely.) >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> >> > > >> > >> >
