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
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
-- 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 (22.214.171.124) for ovirt 4.3.2 will be taken from the
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
v126.96.36.199 -> 4.3.2 RC4 ?!?!
v188.8.131.52 -> 4.3.2 RC5 ?!?!
Perhaps we should move to four versions digit? So we could have
v184.108.40.206 -> 4.3.2 RC1
v220.127.116.11 -> 4.3.2 RC2
v18.104.22.168 -> 4.3.2 RC3
v22.214.171.124 -> 4.3.2 RC4
v126.96.36.199 -> 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,
Senior SW Eng., Virtualization R&D
IRC: fromani github: @fromanirh