Backporting for LTS 2.107.2 started

[Oliver Gondža]

Backporting has started and the RC is scheduled for 2018-03-28.

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
Fixed:
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.107.2-fixed
Rejected:
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.107.2-rejected
--
oliver

[Oleg Nenashev]

I have updated status of https://issues.jenkins-ci.org/browse/JENKINS-50237
IIUC it has been integrated before the LTS RC, so it's going in.

It would be great to get https://issues.jenkins-ci.org/browse/JENKINS-46386 backported, but I am not sure whether it qualifies since it changes web.xml.

BR, Oleg

[Oliver Gondža]

On 2018-03-27 14:18, Oleg Nenashev wrote:
> I have updated status of https://issues.jenkins-ci.org/browse/JENKINS-50237
> IIUC it has been integrated before the LTS RC, so it's going in.
>
> It would be great to get
> https://issues.jenkins-ci.org/browse/JENKINS-46386 backported, but I am
> not sure whether it qualifies since it changes web.xml.

I am tempted to backport it as it negatively impacts people even when
they use default web.xml but the possible breakage is limited to the
people that are using custom (and only when they use it to pass system
properties). Note the people with custom web.xml needs to change it
every now and then so the real question is if asking them to do so in
one LTS line is such big deal.

Please correct me if I miss something...
--
oliver

[Jesse Glick]

On Tue, Mar 27, 2018 at 10:41 AM, Oliver Gondža <ogo...@gmail.com> wrote:
> the possible breakage is limited to the people that

> are using custom [web.xml]

Yes. (Is this even supported?)

> and only when they use it to pass system properties

I do not think so—if they use an old `web.xml` with the new
`jenkins-core.jar` then it will try to attach `SystemProperties` (the
outer class), which is no longer a `ServletListener` so I presume this
would fail startup.

> the people with custom web.xml needs to change it every now and then so the
> real question is if asking them to do so in one LTS line is such big deal.

Otherwise they would just need to change it on upgrade to (e.g.)
2.119.1, so what is the difference? Just something we mention in the
upgrade guide.

[Oleg Nenashev]

Agreed, changing web.xml is not a blocker for backporting

[Oleg Nenashev]

Maybe we also want to backport JENKINS-49737 ("Extras Executable WAR should warn everybody that Java 9+ is not supported") to this or next LTS. It is not a defect, but it gets extremely annoying to process reports about Java 9/10 failures.

Full diff: https://github.com/jenkinsci/extras-executable-war/compare/executable-war-1.37...executable-war-1.38

BR, Oleg

[Daniel Beck]

> On 28. Mar 2018, at 10:29, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> Maybe we also want to backport JENKINS-49737 ("Extras Executable WAR should warn everybody that Java 9+ is not supported") to this or next LTS. It is not a defect, but it gets extremely annoying to process reports about Java 9/10 failures.
>
> Full diff: https://github.com/jenkinsci/extras-executable-war/compare/executable-war-1.37...executable-war-1.38

+1

[Baptiste Mathus]

Late +1 for JENKINS-49737

--
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/94C09B73-4060-401D-8BC8-D647346256C2%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.