[ovirt-devel] [vdsm][maintainership] proposal for a new stable branch policy

[Francesco Romani]

Hi all,


Recently Milan, Petr and me discussed the state of ovirt.4.2,
considering that release 4.2.2 is still pending and this prevents
merging of patches in the sub-branch ovirt-4.2.

We agreed we could improve the handling of the stable branch(es), in
order to make the process smoother and more predictable.


Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...)
as much as we can, to avoid the hassle of double-backporting patches to
stable branch.

However, if a release hits unexpected delay, this policy causes
different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively
locked, so patches already queued

and ready for next releases can't be merged and need to wait.


The new proposed policy is the following:

- we will keep working exactly as now until we hit a certain RC version.
We choosed RC3, a rule of thumb made out of experience.

- if RC3 is final, everyone's happy and things resume as usual

- if RC3 is NOT final, we will branch out at RC3

-- from that moment on, patches for next version could be accepted on
the Y-branch

-- stabilization of the late Z version will continue on the Z-branch

-- patches will be backported twice


Example using made up numbers

- We just released ovirt 4.3.1

- We are working on the ovirt-4.3 branch

- The last tag is v4.30.10, from ovirt-4.3 branch

- We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch

- We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1).
Tag is made from ovirt-4.3 branch.

- Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC
3. Both tags are made from ovirt-4.3 branch.

- Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch
ovirt-4.3 from the same commit pointed by tag 4.30.13

- Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the
ovirt-4.3.2 branch


I believe this approach will make predictable for everyone if and when
the branch will be made, so when the patches could be merged and where.


The only drawback I can see - and that I realized while writing the
example - is the version number which can be awkward:


v4.30.11 -> 4.3.2 RC1

v4.30.12 -> 4.3.2 RC2

v4.30.13 -> 4.3.2 RC3

v4.30.13.1 -> 4.3.2 RC4 ?!?!

v4.30.13.5 -> 4.3.2 RC5 ?!?!


Perhaps we should move to four versions digit? So we could have


v4.30.11.0 -> 4.3.2 RC1

v4.30.11.1 -> 4.3.2 RC2

v4.30.11.2 -> 4.3.2 RC3

v4.30.11.3 -> 4.3.2 RC4

v4.30.11.4 -> 4.3.2 RC5


I don't see any real drawback in using 4-digit versions by default,
besides a minor increase in complexity, which is balanced by more
predictable and consistent
versions. Plus, we already had 4-digit versions in Vdsm, so packaging
should work just fine.

Please share your thoughts,


-- 
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh