[yast-devel] Fixing the version numbers mess in yast2-storage
I have a fix for bug#1008740 and I want to commit it for SP2, CASP and master. We agreed to jump to version 3.2.X in master right after branching SP2... but we didn't do it for yast-storage. :-( Since we didn't jump to 3.2.X on time (we only did it after the 3.1.105 version), we were forced to add a fourth digit for SP2. So SP2 is now 3.1.103.Y Until 3.1.103.2 both CASP and SP2 were in sync. But then we introduced 3.1.103.3 in both version... but with a different fix! So now we have two different 3.1.103.3 versions. :-( Since I want to commit my fix everywhere, I will take the opportunity to fix the mess applying one of these solutions (whatever solution we take, the CASP version HAS to end up with a digit more than SP2, since some changes are CASP-only... so far at least): A) Backport all changes done in master before the jump to 3.2.X. Once that is done, we can bump SP2 to 3.1.106 and fix CASP according. That's problematic because in bug#907331 it's already stated that the fix (only included in yast-storage >= 3.1.105) is not expected to be backported so far. B) Rewrite history. Pretend 3.1.104 and 3.1.105 never existed in TW (they were there between Sept 29th and Oct 31th). Then bump SP2 to 3.1.104 and fix everything from there (CASP would become 3.1.104.1). C) Bump SP2 to 3.1.106 but without backporting the changes. That's inconsistent because 3.1.106 will not include the changes in 3.1.104 and 3.1.105. Those changes will not be in the changelog of SP2, anyways. (CASP would become 3.1.106.1). D) Use the approach in (A) for the changes in 3.1.104 (which should be safe to backport and the approach in (B) for the change in 3.1.105. So rewrite only half of the history. :-) (CASP would become 3.1.105.1) E) Bump SP2 to 3.1.103.4 and bump CASP to 3.1.103.4.1. The downside is obvious, a fifth number in CASP. What do you prefer? Of course you can propose another... as I tend to overlook the easiest one :-) See the three changelogs for details https://github.com/yast/yast-storage/blob/master/package/yast2-storage.chang... https://github.com/yast/yast-storage/blob/SLE-12-SP2-CASP/package/yast2-stor... https://github.com/yast/yast-storage/blob/SLE-12-SP2/package/yast2-storage.c... -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 01/10/2017 01:38 PM, Ancor Gonzalez Sosa wrote:
I have a fix for bug#1008740 and I want to commit it for SP2, CASP and master.
We agreed to jump to version 3.2.X in master right after branching SP2... but we didn't do it for yast-storage. :-(
Since we didn't jump to 3.2.X on time (we only did it after the 3.1.105 version), we were forced to add a fourth digit for SP2. So SP2 is now 3.1.103.Y
Until 3.1.103.2 both CASP and SP2 were in sync. But then we introduced 3.1.103.3 in both version... but with a different fix! So now we have two different 3.1.103.3 versions. :-(
Since I want to commit my fix everywhere, I will take the opportunity to fix the mess applying one of these solutions (whatever solution we take, the CASP version HAS to end up with a digit more than SP2, since some changes are CASP-only... so far at least):
A) Backport all changes done in master before the jump to 3.2.X. Once that is done, we can bump SP2 to 3.1.106 and fix CASP according.
That's problematic because in bug#907331 it's already stated that the fix (only included in yast-storage >= 3.1.105) is not expected to be backported so far.
After talking to Arvin, looks like the reasons to not back-port it were more about convenience than about fearing problems. :-) So I will most likely go with (A) if nobody opposes.
B) Rewrite history. Pretend 3.1.104 and 3.1.105 never existed in TW (they were there between Sept 29th and Oct 31th). Then bump SP2 to 3.1.104 and fix everything from there (CASP would become 3.1.104.1).
C) Bump SP2 to 3.1.106 but without backporting the changes. That's inconsistent because 3.1.106 will not include the changes in 3.1.104 and 3.1.105. Those changes will not be in the changelog of SP2, anyways. (CASP would become 3.1.106.1).
D) Use the approach in (A) for the changes in 3.1.104 (which should be safe to backport and the approach in (B) for the change in 3.1.105. So rewrite only half of the history. :-) (CASP would become 3.1.105.1)
E) Bump SP2 to 3.1.103.4 and bump CASP to 3.1.103.4.1. The downside is obvious, a fifth number in CASP.
What do you prefer? Of course you can propose another... as I tend to overlook the easiest one :-)
See the three changelogs for details
https://github.com/yast/yast-storage/blob/master/package/yast2-storage.chang...
https://github.com/yast/yast-storage/blob/SLE-12-SP2-CASP/package/yast2-stor...
https://github.com/yast/yast-storage/blob/SLE-12-SP2/package/yast2-storage.c...
-- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (1)
-
Ancor Gonzalez Sosa