to start using git-flow from 4.5+, we need to have the latest stable version which can be master and I assumed that would be 4.4 point 2. should be modified assuming no previous releases >> 2a. branch ‘develop’ from 'master’ >> 2b. branch ‘release/4.5' from the develop >> 2c. merge ‘release/4.5' to master once the release voting is done.
Are we waiting for Leo to put up a proposal? ~Rajani On 31-Jul-2014, at 1:09 pm, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > I answerred this from my phone but it did't get through so here my > comment again: > > We can't cut a new master from 4.4 without enormous work. I spend two > days on getting 4.4 in line with 4.4-forward and as Leo has shown the > work for getting all features from master into master will be much > greater. So the proposal should be that we maintain 4.4 as traditional > and start this work flow from 4.5+ > > As for the additions you gave; these are reviewer guidelines for my > part not requirements to a work flow. > > In general I am +1 on putting this to vote. > > On Thu, Jul 31, 2014 at 6:22 AM, Rajani Karuturi > <rajani.karut...@citrix.com> wrote: >> For the git flow: >> 1. We agreed to follow git-flow explained here >> http://nvie.com/posts/a-successful-git-branching-model/ >> 2. This is the proposal for first cut >> 2a. rename 'master' to 'develop’ >> 2b. branch a new 'master' from ‘4.4’ and update tags with release/4.4.0 >> 2c. branch ‘release/4.5' from the develop >> 2d. merge ‘release/4.5' to master once the release voting is done. >> 3. This would be the flow for a hot fix >> 3a. branch off from the release tag on master. in this case it would be >> release/4.4.0 >> 3b. commit the fixes in hotfix/4.4.1 >> 3c. do the release >> 3d. merge to develop >> 3e. merge to master and update tags >> 3f. delete hot fix branch >> 4. for any LTS release create a support branch when required using git-flow >> support >> 4a. http://stackoverflow.com/a/16866118/201514 >> >> using the git-flow git extension available at >> https://github.com/nvie/gitflow can reduce the number of commands/errors >> >> In addition: >> 1. Every commit should have unit tests >> 2. every feature/merge request should have unit and marvin integration tests >> 3. A commit should not have check style or find bugs issues >> 4. any coverity issues reported in the new code should be addressed >> immediately >> 5. every developer should run the BVT on the simulator before doing a >> checkin >> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes,+using+Simulator>) >> (This I am not very sure. May be we should let jenkins handle it and report >> integration failures if any?) >> Please add/amend if I missed anything. >> >> Can we call for a vote on this and freeze this without further delay? >> >> >> ~Rajani >> >> >> > > > > -- > Daan
