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