On Tue, 4 Oct 2016 13:58:30 +0200
Ancor Gonzalez Sosa <[email protected]> wrote:

> 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 <[email protected]> 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.

Well, self update will require quite intensive QA testing, so I am not
sure how often we want to run such procedure. Question for release
manager or maintenance ones?

Josef
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to