[yast-devel] Re: [yast-internal] Version numbers post-SP3 (Factory / SLE-15)
On 08/09/2017 01:19 PM, Stefan Hundhammer wrote:
The SP3 branch uses 3.2.x .
When we keep using 3.2.x in master as well, we need to start using a fourth digit in that branch: 3.2.x.1 etc.
Since we are not targeting a new product, we might want to bump one of the numbers in master:
(a) Start with 3.3.1
(b) Start with 15.xxx as Jiri suggested: (b1) 15.1 ? (b2) 15.0.1 ? (b3) 15.1.1 ?
I like this one. We could use the first number (which is somehow fixed right now) so it will be crystal clear which is the next number to use. 15.0.x SLE 15 SP0 15.1.x SLE 15 SP1 15.2.x SLE 15 SP2 ... (We can use "4" if you do not like "15") == Bumping versions == The controversial point is when to bump those numbers and, after discussing it with Ancor and Ivan, we have reached some kind of agreement. Let's say SLE 15 (SP0) was already released and let's say we have a package yast2-example 15.0.0. Moreover, we have a SLE-15 branch in our repositories. * Every fix/change that goes as a MU, will go to branch SLE-15 and it will increment the last number (15.0.1, 15.0.2, etc.). Of course, all those changes will be merged into master but we'll keep the same number as far as we do not diverge. * The first change that introduces a divergence between SLE-15 and master branches should bump the second number: 15.1.0 (SLE 15, SP1). Fast forward: SLE 15 SP3 was released. Current yast2-example version is 15.1.5 (the package has not diverged since SLE 15 SP1). If I want to introduce a fix in the SLE-15-SP3 branch, I would bump to 15.3.0. Note that I've just ignored 15.2.x completely. So the second number will indicate the last SPX where the package diverged. 15. | +------> SP where the package diverged +------> Major SUSE version (4, 5, 15... whatever we decide) == Releasing a new open(SUSE) version == Let's suppose that, after SLE 16 has been released, we are going to publish SLE 15 SP4. I *guess* that it should be based on SLE 15 SP3. master -> 16.0.0 SLE-15-SP4 -> 15.4.0 (if already diverged from SLE 15 SP3) SLE-15-SP3 -> 15.3.X SLE-15-SP2 -> 15.1.5 (if it has not diverged since SP1) SLE-15-SP1 -> 15.1.5 SLE-15-SP0 -> 15.0.2 (for instance). Our 2 cents. Regards, Imo -- Imobach González Sosa YaST team at SUSE LINUX GmbH Blog: https://imobachgs.github.io/ Twitter: @imobachgs
Sorry, wrong list. On 08/09/2017 05:02 PM, Imobach Gonzalez Sosa wrote:
On 08/09/2017 01:19 PM, Stefan Hundhammer wrote:
The SP3 branch uses 3.2.x .
When we keep using 3.2.x in master as well, we need to start using a fourth digit in that branch: 3.2.x.1 etc.
Since we are not targeting a new product, we might want to bump one of the numbers in master:
(a) Start with 3.3.1
(b) Start with 15.xxx as Jiri suggested: (b1) 15.1 ? (b2) 15.0.1 ? (b3) 15.1.1 ?
I like this one. We could use the first number (which is somehow fixed right now) so it will be crystal clear which is the next number to use.
15.0.x SLE 15 SP0 15.1.x SLE 15 SP1 15.2.x SLE 15 SP2 ...
(We can use "4" if you do not like "15")
== Bumping versions ==
The controversial point is when to bump those numbers and, after discussing it with Ancor and Ivan, we have reached some kind of agreement.
Let's say SLE 15 (SP0) was already released and let's say we have a package yast2-example 15.0.0. Moreover, we have a SLE-15 branch in our repositories.
* Every fix/change that goes as a MU, will go to branch SLE-15 and it will increment the last number (15.0.1, 15.0.2, etc.). Of course, all those changes will be merged into master but we'll keep the same number as far as we do not diverge.
* The first change that introduces a divergence between SLE-15 and master branches should bump the second number: 15.1.0 (SLE 15, SP1).
Fast forward: SLE 15 SP3 was released. Current yast2-example version is 15.1.5 (the package has not diverged since SLE 15 SP1). If I want to introduce a fix in the SLE-15-SP3 branch, I would bump to 15.3.0. Note that I've just ignored 15.2.x completely. So the second number will indicate the last SPX where the package diverged.
15. | +------> SP where the package diverged +------> Major SUSE version (4, 5, 15... whatever we decide)
== Releasing a new open(SUSE) version ==
Let's suppose that, after SLE 16 has been released, we are going to publish SLE 15 SP4. I *guess* that it should be based on SLE 15 SP3.
master -> 16.0.0 SLE-15-SP4 -> 15.4.0 (if already diverged from SLE 15 SP3) SLE-15-SP3 -> 15.3.X SLE-15-SP2 -> 15.1.5 (if it has not diverged since SP1) SLE-15-SP1 -> 15.1.5 SLE-15-SP0 -> 15.0.2 (for instance).
Our 2 cents.
Regards, Imo
-- Imobach González Sosa YaST team at SUSE LINUX GmbH Blog: https://imobachgs.github.io/ Twitter: @imobachgs
participants (1)
-
Imobach Gonzalez Sosa