On Jul 24, 2014, at 10:45 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> Any advice on our procedure from this, Leo?
Yes, to follow all the git-flow defaults [1].
* goal is for master to become stable
* new develop which starts from master
* create with `git flow init`
* ‘abandon’ 4.4 / 4.4-forward
* anything in there which is not currently
in master gets cherry-picked into develop
* accordingly, plan is no 4.4.1
* if 4.4.1 becomes really necessary, create
it by cherry-picking from develop
* keep 4.3 to produce 4.3.1 then
abandon it, too
It is important to realize that a git-flow release/4.5 is _not_ the same as an
old-style 4.5-forward; a lot more discipline is required.
4.4-forward contains a lot of things which are not purely bugfixes. 4.4-forward
has additional tests, lots of changes to test suites, things that should go in
4.4.1 but not 4.4.0, half-merged features that were pulled from 4.4 but remain
in 4.4-forward, bugfixes that include refactoring, etc etc. In a git-flow
model, those things would go onto feature/ and/or support/ branches, and from
there to the develop branch, and definitiely _never_ onto a release branch. It
was very hard to get 4.4 stable by cherry-picking from 4.4-forward; the
discipline suggested by git-flow is _exactly_ to avoid that difficulty.
Note git-flow defaults also include:
* feature branches are called feature/feature-thing
(don’t put your name in there, its meant to be
descriptive!)
* release branches are called release/{version}
(not RELEASE-{version})
* hotfixes are called hotfix/{version}-name
and are based on & merge to master (not usually
to a release branch, release branches are not
hot, hotfixes are patches to previous releases,
i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
* everyone can commit on release branches,
everyone can merge to develop (generally you
don’t need much merging to release branches
since the only thing you commit there are
bugfixes, you merge _from_ the release branch
_to_ the develop branch), merging is _not_ a
release manager's job (the release manager might
review or approve bugfixes, but its the committer
that merges)
* no cherry-picking!
cheers,
Leo
[1] unfortunately, the reason I did this analysis work yesterday was to try and
find a way to start from 4.4 and go forward from there, first merging in
4.4-forward and then master, but I don’t see that happening
> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <lsim...@schubergphilis.com>
> wrote:
>> branch two diff size big diff chunks
>> branch one
>> 4.3 4.4 11MB hyperv,netscaler,server,engine
>> 4.4 4.4-forward 2MB tests,marvin
>> 4.4-forward master 6MB xenapi,xen,xenserver,storage
>> 4.4 master 8MB xenapi,tests,marvin,xen,xenserver
>> (See below how I got the numbers.)
>>
>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from
>> master means processing hundreds of thousands of lines of diff. Of those
>> lines, many many thousands of lines will probably not auto-merge due to the
>> cherry-pick approach. A rebase between any of these branches is not
>> feasible; git cannot un-pick what happened so it cannot offer much
>> assistance.
