Mailinglist Archive: yast-devel (53 mails)

< Previous Next >
Re: [yast-devel] Fixing the version numbers mess in yast2-storage
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

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

Until both CASP and SP2 were in sync. But then we introduced in both version... but with a different fix! So now we have
two different 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

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

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

E) Bump SP2 to and bump CASP to 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

Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >