I fully second Todd.
Thanks,Yuliya
From: Todd Richmond <[email protected]>
To: [email protected]
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 <[email protected]> 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.)
