Mailinglist Archive: yast-devel (87 mails)

< Previous Next >
Re: [yast-devel] Versioning the SLE-12-SP2-CASP branch


On 03/02/17 10:44, Ancor Gonzalez Sosa wrote:
Josef and me are discussing how to version stuff in CASP vs SP2 when
both branches are getting different subset of changes. Always taking
into account that, when CaaSP is released, the SP2 branch should contain
all the changes and the CASP branch should die.

Let's take an example (disclaimer, you will probably need to open this
mail in three windows to follow the reasoning and see the differences):

Jan 1st, both SP2 and CASP are in sync.
Feb 1st, we introduce change A only in CASP
March 1st, we introduce change B only in CASP
April 1st, we introduce change C in SP2 and we merge into CASP
(remember we should merge into CASP EVERY change done to SP2)
May 1st, we introduce change D in CASP and we consider the code in CASP
is ready for entering the SP2 branch (remember the plan is to merge
into SP2 as soon as it's safe).
June 1st, we introduce change E in SP2
(and, of course, we merge in CASP
July 1st, we introduce change F in CASP
...


The approach suggested by Josef
===============================
Josef, suggest to rewrite history in the CASP branch to make merging
back to SP2 easier. After all, the CASP branch will die at some point
and its history will not be relevant anymore.

Status at Jan 1st
CASP changelog says:
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at Feb 1st
CASP changelog says:
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at March 1st
CASP changelog says:
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at April 1st (after the merge)
CASP changelog says:
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

SP2 changelog says:
3.1.11 Change C
3.1.10 Blah

Status at May 1st (after the merge)
CASP changelog says:
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

SP2 changelog says:
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

Status at June 1st (after the merge)
CASP changelog says:
3.1.13 Change E
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

SP2 changelog says:
3.1.13 Change E
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

Status at July 1st
CASP changelog says:
3.1.13.1 Change F
3.1.13 Change E
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

SP2 changelog says:
3.1.13 Change E
3.1.12 Change D
3.1.11.1 CASP changes (A and B)
3.1.11 Change C
3.1.10 Blah

The approach suggested by me
============================
The approach above constantly rewrites the CASP branch changelog to make
the impression that CASP and SP2 has always evolved hand by hand.
I believe the risk to create confusion (or to make-up history too much
and loose information) is bigger than the gain. I propose this:

Status at Jan 1st
CASP changelog says:
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at Feb 1st
CASP changelog says:
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at March 1st
CASP changelog says:
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.10 Blah

Status at April 1st (after the merge)
CASP changelog says:
3.1.11.1 Change C
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.11 Change C
3.1.10 Blah

Status at May 1st (after the merge)
CASP changelog says:
3.1.12 Change D
3.1.11.1 Change C
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.12 Changes A, B and D
3.1.11 Change C
3.1.10 Blah

Status at June 1st (after the merge)
CASP changelog says:
3.1.13 Change E
3.1.12 Change D
3.1.11.1 Change C
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.13 Change E
3.1.12 Changes A, B and D
3.1.11 Change C
3.1.10 Blah

Status at July 1st
CASP changelog says:
3.1.13.1 Change F
3.1.13 Change E
3.1.12 Change D
3.1.11.1 Change C
3.1.10.2 Change B
3.1.10.1 Change A
3.1.10 Blah

SP2 changelog says:
3.1.13 Change E
3.1.12 Changes A, B and D
3.1.11 Change C
3.1.10 Blah

What others think?

I would go for the second approach and avoid rewriting the history. IMHO
that approach reflects reality better.

Regards,
Imo

--
Imobach González Sosa
YaST team at SUSE LINUX GmbH
Blog: https://imobachgs.github.io/
Twitter: @imobachgs

< Previous Next >
References