LTS baseline selection for the successor of 2.235

98 views
Skip to first unread message

Oliver Gondža

unread,
Jul 29, 2020, 6:00:50 AM7/29/20
to jenkin...@googlegroups.com
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

Antonio Muñiz

unread,
Jul 29, 2020, 7:14:37 AM7/29/20
to jenkin...@googlegroups.com
This is the full list of bugs reported after the previous LTS release date.
I had a quick look and I don't see anything clearly blocking the LTS release (JENKINS-63082 smells bad, but it was already in the previous LTS, so not a regression).

2.249 looks good to me.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3292bcc0-2fb5-08ab-51b6-fb88f53c0eb4%40gmail.com.


--
Antonio Muñiz
Human, Engineer
CloudBees, Inc.

Ullrich Hafner

unread,
Jul 29, 2020, 7:20:25 AM7/29/20
to Jenkins Developers
That means that we have the intermediate black table headers in it :-( 

Daniel Beck

unread,
Jul 29, 2020, 7:54:42 AM7/29/20
to JenkinsCI Developers
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 number but might cause confusion with 2.150 which was also an LTS baseline, so would tentatively prefer 2.249 for greater Hamming distance.


To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0B575C1E-06AD-4D04-BDA2-0424269AAB8F%40gmail.com.


--

Daniel Beck
Senior Software Engineer
CloudBees, Inc.

 


Oleg Nenashev

unread,
Jul 29, 2020, 7:59:38 AM7/29/20
to Jenkins Developers
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 will be able to prepare and integrate the fixes by the next LTS RC in 4 weeks. If we want to take older version without regressions, it would be 2.247 which lacks many other important patches. I'd rather go ahead with the version and get it fixed.
+1 to Daniel's comment about UI changes. As discussed at the last UX SIG meeting we have an option to backport fixes for UI before the RC date if there is a consensus.

Best regards,
Oleg

On Wednesday, July 29, 2020 at 1:54:42 PM UTC+2, Daniel Beck wrote:
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 number but might cause confusion with 2.150 which was also an LTS baseline, so would tentatively prefer 2.249 for greater Hamming distance.


On Wed, Jul 29, 2020 at 1:20 PM Ullrich Hafner <ullric...@gmail.com> wrote:
That means that we have the intermediate black table headers in it :-( 
Am 29.07.2020 um 13:14 schrieb Antonio Muñiz <amu...@cloudbees.com>:

This is the full list of bugs reported after the previous LTS release date.
I had a quick look and I don't see anything clearly blocking the LTS release (JENKINS-63082 smells bad, but it was already in the previous LTS, so not a regression).

2.249 looks good to me.

On Wed, 29 Jul 2020 at 12:00, Oliver Gondža <ogo...@gmail.com> wrote:
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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.


--
Antonio Muñiz
Human, Engineer
CloudBees, Inc.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

Tim Jacomb

unread,
Jul 29, 2020, 9:03:57 AM7/29/20
to Jenkins Developers
I vote for 2.250, with some backporting needed.

Thanks
Tim

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/aadb0f8f-7847-4ad6-a5a0-e396f03bbabeo%40googlegroups.com.

Matt Sicker

unread,
Jul 29, 2020, 10:20:47 AM7/29/20
to jenkin...@googlegroups.com
If you're going by neat numbers, 2.255 would be the coolest. ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BiemXRGrxXv_%3DiPXvi6y3LQKcreT0Z3DWAqF-panTEjosA%40mail.gmail.com.


--
Matt Sicker
Senior Software Engineer, CloudBees

Daniel Beck

unread,
Jul 30, 2020, 4:22:32 PM7/30/20
to Jenkins Developers


> On 29. Jul 2020, at 13:59, Oleg Nenashev <o.v.ne...@gmail.com> 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 looking number.

Mark Waite

unread,
Jul 30, 2020, 5:18:38 PM7/30/20
to jenkinsci-dev
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.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/374FBAD1-9229-4EC1-B333-1B1BF1B299B5%40beckweb.net.

Jesse Glick

unread,
Jul 31, 2020, 12:11:55 PM7/31/20
to Jenkins Dev
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.

Mark Waite

unread,
Jul 31, 2020, 1:11:33 PM7/31/20
to jenkinsci-dev
I think we may have different people that we're trying to avoid confusing.  I would expect developers to be confused that we chose 2.249 and backported a change that was in 2.250 (along with other changes).  I think we should accept that they may be confused by that choice.  I believe the goal in choosing 2.249 is to reduce confusion for users as they are reporting an issue.  They are less likely to make a mistake listing the version number as 2.249 than if it were 2.250.

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.

Mark Waite
 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Daniel Beck

unread,
Jul 31, 2020, 3:42:50 PM7/31/20
to JenkinsCI Developers
On Fri, Jul 31, 2020 at 7:11 PM Mark Waite <mark.ea...@gmail.com> 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 we shouldn't, see core maintainer guidelines) that release should be a safe choice too. Don't know whether Oliver would be OK with that approach given we deliberately moved the baseline decision earlier.

ogondza

unread,
Aug 1, 2020, 4:30:41 AM8/1/20
to Jenkins Developers
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 weekly and LTS separately and I doubt they care much how specifically it have happened.

So, I am declaring 2.249 a winner.

As always, thanks a lot for all the inputs! Even when your suggestions was not followed, please keep them coming to ensure the hight quality of the results produced.

Thanks!
--
oliver

Oleg Nenashev

unread,
Aug 5, 2020, 10:00:53 AM8/5/20
to Jenkins Developers
Thanks Oliver! I have added the target dates for 2.249.1 to the event calendar.
Reply all
Reply to author
Forward
0 new messages