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