Hi Leo, Thanks for the detailed wiki. shouldn’t we use git flow support for LTS releases? http://stackoverflow.com/a/16866118/201514
~Rajani On 04-Aug-2014, at 7:29 pm, Leo Simons <lsim...@schubergphilis.com> wrote: > Hey folks, > > Since Daan volunteered me to do some docs, I’ve updated Rohit’s page at > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git > > with additional details. > > I went back through all the e-mails on the subject to find > questions/concerns, addressed the ones I think have consensus and highlighted > a few places where additional decision/discussion may be needed. > > Remaining topics I’m not sure about: > * when to cut over > * how to cut over > * policy for who merges to release branches > * policy for adding features in micro releases > * what to name hot fixes > > Comments on each below. > > When to cut over > ---------------- > I think docs are quite sufficient now. I’d personally suggest to just do it. > > Since the vote is done I think any committer should feel free to pick up the > ball :) > > How to cut over > --------------- > * Someone has to make the branches and announce the flip on the mailing list. > * Everyone has to flip / git flow init / etc. > * Someone has to update jenkins.buildacloud.org to build the new develop > branch. > * ??? > * Profit. > > Again, I’d personally suggest to just do it. > > Policy for who merges to release branches > ----------------------------------------- > There was some unresolved discussion about > 1. when it is ok to directly commit to the release branch > 2. when it is ok for other people than the release manager to merge to the > release branch > 3. when/how to do a freeze of a release branch > > Git flow says: > 1. basically never > 2. what’s a release manager? > 3. never, cut release branch == feature freeze, tag release == freeze > > Personally I would suggest > 1. never unless you are doing release management (i.e. version bump) commits > 2. always as long as you are confident and prepared to suffer the wrath of > doing it wrong, ask the release manager to do it if you are not confident > 3. at the jurisdiction of the release manager > > Policy for adding features onto release branches > ------------------------------------------------ > It has been cloudstack practice to include new features (or enable features) > in micro releases. > > I did document how to do this within the git-flow model, but I strongly > suggest to simply stop doing it. > > I suggest the policy is that this can be done as an exception to the rule > after discussion on the mailing list, using lazy consensus, with the release > manager doing the merge to the release branch. > > what to name hotfixes > --------------------- > hotfix/<jira-ticket> > > the -<summary> should be descriptive and is optional. > > hotfix/4.4-<jira-ticket> > > for fixes to 4.4.x. > > > > cheers, > > > > Leo >
