cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 19:26:30 GMT
On Wed, Aug 6, 2014 at 7:30 PM, Alena Prokharchyk <
Alena.Prokharchyk@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message