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