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