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