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