On Wed, Aug 6, 2014 at 7:30 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote:
> Rohit, thank you for the explanation. So we cut the maintenance release > from the master branch, not *develop as opposed to the major release > branch. > > Here's what happens if you want to create a support (ie maintenance release) branch, in this example I'll use 4.3.1 as example maintenance version number. > git checkout 4.3.0 ( this should be the release tag) > git checkout -b support/4.3.x > git checkout -b hotfix/4.3.1 ... make your fix, then: > git checkout support/4.3.x > git merge hotfix/4.3.1 > git branch -d hotfix/4.3.1 > git tag 4.3.1 If you install the gitflow tools you don't do all this yourself, instead you would do this: > git flow support start 4.3.x 4.3.0 > git flow hotfix start 4.3.1 support/4.3.x ... make changes then: > git flow hotfix finish 4.3.1 As you can see the support/4.3.x branch persists, and a subsequent release 4.3.2 would be branched off that. One more open question. Its clear that we cut the maintenance release from > the master branch, but what would be the right way to merge it back if > this is a maintenance release for say 4.2, and 4.4 is the top of the > master branch? Where would the 4.2.1 tag appear? It can’t be on a top of > 4.4 > > You don't merge it back to master unless the maintenance would be the latest release. (i'm not even sure if you do it then) > > All the above should be documented in the proposal. The original proposal > didn’t mention anything about how we are going to do maintenance branches. > And we were originally thinking about leaving the release branches around. > > Gitflow has a concept for this, it's called support branch/releases. -- Erik
