On 10/04/2016 01:02 PM, Ancor Gonzalez Sosa wrote:
On 10/04/2016 12:50 PM, Josef Reidinger wrote:
On Tue, 4 Oct 2016 12:19:47 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
[...]
My suggestion, start using 3.2.X for master. We can correct the already released packages not using that versioning schema. They shouldn't be many.
So the solution would look like this(for the yast2-packager example)
SLE-12-SP2 (SP2 in OBS) -> 3.1.118, 3.1.119... master (TW in OBS) -> 3.2.1, 3.2.2... merge_after_release (Leap and SP2:Update) -> 3.1.117.1, 3.1.117.2...
this is wrong, as SP2 have higher number then merge_after_release. What abou 3.1.117.1 reserved for SP2 and 3.1.118 for merge_after_release?
Yes, that obviously makes much more sense. I was just writing from the top of my mind, without thinking it twice.
in general I agree with 3.2.* versioning jump. ( just keep it in mind when dumping master )
Changes introduced in SLE-12-SP2 should also be merged in merge_after_release (producing a new number there) and the final merge after release should bump the number to follow the SLE-12-SP2 series.
I think that better way is to merge merge_after_release to SP2 branch and use its new higher number. Also I expect that all fixes in SP2 will be in Leap, so all changes in SP2 have to be in merge_after_release.
Yes, as said. Makes more sense.
And next question is, what will be release through self-update? Everything from the merge_after_release branches will be published in the self-update repo? Just asking, I don't see a reason to not do it. For example, I already have a trivial fix for this yast-bootloader bug https://bugzilla.suse.com/show_bug.cgi?id=1000629 I plan to merge it in merge_after_release and master... and it looks exactly as the kind of things we created self-update for. Cheers. -- 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