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.) > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > > > >
