Re: LTS baseline selection for the successor of 2.235

2020-08-05 Thread Oleg Nenashev
Thanks Oliver! I have added the target dates for 2.249.1 to the event calendar. On Saturday, August 1, 2020 at 10:30:41 AM UTC+2, ogondza wrote: > > Avoiding 2.250 so it is not confused with 2.150 is an interesting > suggestion, though it does not outweigh stability so 2.249 is preferable >

Re: LTS baseline selection for the successor of 2.235

2020-08-01 Thread ogondza
Avoiding 2.250 so it is not confused with 2.150 is an interesting suggestion, though it does not outweigh stability so 2.249 is preferable over 2.251. I do not think backporting the only fix from 2.250 to 2.249 is going to confuse anyone: users need to track *when* the fix was introduced in

Re: LTS baseline selection for the successor of 2.235

2020-07-31 Thread Daniel Beck
On Fri, Jul 31, 2020 at 7:11 PM Mark Waite wrote: > We could also choose 2.251 and have the most of the same improvement in > clarity for user communication, but it would bring the other changes from > 2.251 into the LTS baseline. > Unless we merge something potentially causing regressions (and

Re: LTS baseline selection for the successor of 2.235

2020-07-31 Thread Mark Waite
On Fri, Jul 31, 2020 at 10:11 AM Jesse Glick wrote: > Seems more confusing to me to take 2.249 given that you will > immediately need to backport the one non-cosmetic change in 2.250 > (#4879) but it does not really matter much one way or the other. > > I think we may have different people that

Re: LTS baseline selection for the successor of 2.235

2020-07-31 Thread Jesse Glick
Seems more confusing to me to take 2.249 given that you will immediately need to backport the one non-cosmetic change in 2.250 (#4879) but it does not really matter much one way or the other. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers"

Re: LTS baseline selection for the successor of 2.235

2020-07-30 Thread Mark Waite
I agree with Daniel that we should prefer 2.249 or consider 2.251 so that we avoid confusion in bug reports. I also like that Ulli noted it increases the Hamming distance. It has been a while since I thought about Hamming codes. On Thu, Jul 30, 2020 at 2:22 PM Daniel Beck wrote: > > > > On

Re: LTS baseline selection for the successor of 2.235

2020-07-30 Thread Daniel Beck
> On 29. Jul 2020, at 13:59, Oleg Nenashev wrote: > > 2.250 is a fancy number, so why not? As I previously explained, too similar to 2.150 which was also an LTS baseline. Since there's no other notable difference to 2.249, I would prefer less confusing bug reports over having a nice

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Matt Sicker
If you're going by neat numbers, 2.255 would be the coolest. ;) On Wed, Jul 29, 2020 at 8:03 AM Tim Jacomb wrote: > I vote for 2.250, with some backporting needed. > > Thanks > Tim > > On Wed, 29 Jul 2020 at 12:59, Oleg Nenashev > wrote: > >> Hi all, >> >> I would vote for 2.250. 2.250 has no

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Tim Jacomb
I vote for 2.250, with some backporting needed. Thanks Tim On Wed, 29 Jul 2020 at 12:59, Oleg Nenashev wrote: > Hi all, > > I would vote for 2.250. 2.250 has no functional difference from 2.249, > there is just one internal fix. 2.250 is a fancy number, so why not? > > 2.249/2.250 still have

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Oleg Nenashev
Hi all, I would vote for 2.250. 2.250 has no functional difference from 2.249, there is just one internal fix. 2.250 is a fancy number, so why not? 2.249/2.250 still have issues after the .NET Framework 2.0 support removal. Both issues need some fixes and upgrade guidelines. I believe that I

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Daniel Beck
Is this about https://github.com/jenkinsci/jenkins/pull/4867 ? We can always backport that change if needed. Or, with some merge discipline we could tentatively choose 2.251 and fall back to 2.250/2.249 (which are basically identical) if something we don't want makes it in. 2.250 is a nicer

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Ullrich Hafner
That means that we have the intermediate black table headers in it :-( > Am 29.07.2020 um 13:14 schrieb Antonio Muñiz : > > This is the full list of bugs reported after the previous LTS release date >

Re: LTS baseline selection for the successor of 2.235

2020-07-29 Thread Antonio Muñiz
This is the full list of bugs reported after the previous LTS release date . I

LTS baseline selection for the successor of 2.235

2020-07-29 Thread Oliver Gondža
Let's voice the baseline candidates and concerns so we have the candidate agreed on by the end of the week. To get the discussion started, how about 2.249? https://jenkins.io/changelog/ -- oliver -- You received this message because you are subscribed to the Google Groups "Jenkins