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