Re: Using JDK 11 instead of JDK 8 in default docker images

[Jesse Glick]

Due to the way Jenkins performs remote class loading and allows plugins to
implement callables, is is impractical to support Java 8 on agents without
forcing Jenkins core and all commonly used plugins to run on 8 as well.

At worst, builds on exotic OSs with poor Java support can still be done by
running the Jenkins agent on, say, Linux and having the actual build steps
be run via SSH or some similar remote CLI (with support for file transfer
like SCP where required). It would even be possible to write a plugin
offering a Pipeline step to run commands on a specified host using SSH
without requiring an executor slot (Scripted: no `node`; Declarative:
`agent none`). You would not get access to rich publisher steps like
`recordIssues` but it might be good enough most of the time, especially if
you can cross-compile or whatever from Linux and the only things that truly
must be done on the special OS are integration tests.

At any rate, so far there is no strong push to drop 8 support so this
remains discussion about an indefinite future.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1hJezjx0Ge99SA_nVF%3Dr98pCuxDhjWPA0XwDoqC%3Drs1A%40mail.gmail.com.

RE: Using JDK 11 instead of JDK 8 in default docker images

[Bill Honaker]

The question to ask is, was that minimum version due to the ‘default’ action of 
javac (that is, -target 11),  or because they required something that doesn’t 
exist in Java 8?

 

It won’t solve all problems but ‘projects’ that are intended to be dependencies 
for other projects would be better if the above question were asked in the 
design phase.  That’s just my $.02US, for what it’s worth.

Bill

 

From: jenkinsci-dev@googlegroups.com  On Behalf 
Of Tim Jacomb
Sent: Wednesday, August 11, 2021 2:46 PM
To: jenkinsci-dev@googlegroups.com
Subject: Re: Using JDK 11 instead of JDK 8 in default docker images

 

Jetty, Hikari, and opensaml are all projects I’ve come across recently where 
new development has a minimum Java 11 version… there’s probably many others

 

On Wed, 11 Aug 2021 at 16:03, Matt Sicker mailto:boa...@gmail.com> > wrote:

Plus Java 17 comes out really soon. I can imagine that will inspire more 
projects to set Java 11 as a baseline. Definitely start planning since most 
people will probably be affected by some other dependencies well before they 
hit Jenkins.

Matt Sicker





On Aug 11, 2021, at 09:18, jn...@cloudbees.com   
mailto:jn...@cloudbees.com> > wrote:

Hi Bill (et al) for those that are running nonstop or the like and have an 
update / test cycle in the order of 6 months :


I would recommend that your customers probably want to start the planning / 
validation to update to Java11 now even if this LTS version still runs on 
Java8.  Java11 is going to happen at some point and I am not sure the project 
will be able to give you all the advance notice you need.

 

Jenkins has supported Java11 for a while now, and if there are any specifics 
from you that cause it not to run we would like to be aware as early as 
possible (it won;t help you if we find out after the switch has been made and 7 
days before a go live)

>  Most of your customers don't spend time reviewing this group.  And many 
> Enterprise decisionmakers don't participate in Twitter, which leaves the 
> results of surveys in that platform somewhat questionable.

On that note - where should we announce surveys / things like this - if users 
are not in the user email / discored or the like how can we reach people to 
inform them and have them participate?

I also work for a company (CloudBees) that has Jenkins at its core for 
Enterprise customers, so we have the statistics from these installations as 
well - so this project is not blind of enterprises (and if a customer wants a 
version of Jenkins that is supported for 9 months rather than the normal 3 we 
can probably help you out, and there may be others) 

 

Regards

 

/James

On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com 
  wrote:

Mark,

 

Randall had pointed me to this thread.  I admit to only reading the last couple 
of dozen posts and, based only on that, share my concerns.  I should have spent 
more time reading the thread, but I was scheduled to do a code walkthrough with 
my customer and took the 'short' path, for which I apologize.

 

Your clarification does seem 100% the right thing to do, and I thank you for 
sharing it.  That's worth much  more than .02$US!

 

And my customers all never need know I ever had this concern, you had it  
covered. :-)

 

Bill

On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:

Thanks for sharing your insights.  Great to have participation in the thread.  
Comments are inline

 

On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:

Similar to Randall (the.n...), I have customers that use NonStop, but they also 
use various distros of Enterprise Linux.  Their corporate strategy for software 
development is to remain on Java 8 for the foreseeable future, primarily due to 
the JDK  11 licensing mentioned above.  They have a corporate support contract 
with Oracle to continue to get Java 8 updates, so support is not an issue for 
them.  Shipping a version of Jenkins that won't do 'remoting' on those target 
platforms should require much longer than 5 months of advance notice, as those 
customers are on much longer strategic cycles.

 

 

I'm not sure where you're getting the idea that we would be shipping a version 
of Jenkins that won't do 'remoting' on those target platforms.  The proposal 
does not remove Java 8 support.  The proposal does not prevent users from 
running agents or controllers or both with Java 8.  The proposal does not 
change how 'remoting' operates.

 

 

Even though  the newer platforms and releases for NonStop  include both Java 8 
and Java 11, customers on NonStop and Linux that are Enterprise-focused (and 
there are MANY) haven't installed Java 11 and have no plan to do so  this year 
or probably even next.  What was the penetration number above for Java 11, only 
4%?  Expecting a large percentage of your customer base to make this move is 
short-sighted.

 

 

We're not expecting them to make a 

Re: Using JDK 11 instead of JDK 8 in default docker images

[Tim Jacomb]

Jetty, Hikari, and opensaml are all projects I’ve come across recently
where new development has a minimum Java 11 version… there’s probably many
others

On Wed, 11 Aug 2021 at 16:03, Matt Sicker  wrote:

> Plus Java 17 comes out really soon. I can imagine that will inspire more
> projects to set Java 11 as a baseline. Definitely start planning since most
> people will probably be affected by some other dependencies well before
> they hit Jenkins.
>
> Matt Sicker
>
> On Aug 11, 2021, at 09:18, jn...@cloudbees.com 
> wrote:
>
> Hi Bill (et al) for those that are running nonstop or the like and have
> an update / test cycle in the order of 6 months :
>
>
> I would recommend that your customers probably want to start the planning
> / validation to update to Java11 now even if this LTS version still runs on
> Java8.  Java11 is going to happen at some point and I am not sure the
> project will be able to give you all the advance notice you need.
>
> Jenkins has supported Java11 for a while now, and if there are any
> specifics from you that cause it not to run we would like to be aware as
> early as possible (it won;t help you if we find out after the switch has
> been made and 7 days before a go live)
>
> >  Most of your customers don't spend time reviewing this group.  And many
> Enterprise decisionmakers don't participate in Twitter, which leaves the
> results of surveys in that platform somewhat questionable.
>
> On that note - where should we announce surveys / things like this - if
> users are not in the user email / discored or the like how can we reach
> people to inform them and have them participate?
>
> I also work for a company (CloudBees) that has Jenkins at its core for
> Enterprise customers, so we have the statistics from these installations as
> well - so this project is not blind of enterprises (and if a customer wants
> a version of Jenkins that is supported for 9 months rather than the normal
> 3 we can probably help you out, and there may be others)
>
> Regards
>
> /James
> On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com wrote:
>
>> Mark,
>>
>> Randall had pointed me to this thread.  I admit to only reading the last
>> couple of dozen posts and, based only on that, share my concerns.  I should
>> have spent more time reading the thread, but I was scheduled to do a code
>> walkthrough with my customer and took the 'short' path, for which I
>> apologize.
>>
>> Your clarification does seem 100% the right thing to do, and I thank you
>> for sharing it.  That's worth much  more than .02$US!
>>
>> And my customers all never need know I ever had this concern, you had it
>> covered. :-)
>>
>> Bill
>> On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:
>>
>>> Thanks for sharing your insights.  Great to have participation in the
>>> thread.  Comments are inline
>>>
>>> On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:
>>>
 Similar to Randall (the.n...), I have customers that use NonStop, but
 they also use various distros of Enterprise Linux.  Their corporate
 strategy for software development is to remain on Java 8 for the
 foreseeable future, primarily due to the JDK  11 licensing mentioned
 above.  They have a corporate support contract with Oracle to continue to
 get Java 8 updates, so support is not an issue for them.  Shipping a
 version of Jenkins that won't do 'remoting' on those target platforms
 should require much longer than 5 months of advance notice, as those
 customers are on much longer strategic cycles.


>>> I'm not sure where you're getting the idea that we would be shipping a
>>> version of Jenkins that won't do 'remoting' on those target platforms.  The
>>> proposal does not remove Java 8 support.  The proposal does not prevent
>>> users from running agents or controllers or both with Java 8.  The proposal
>>> does not change how 'remoting' operates.
>>>
>>>
>>>
 Even though  the newer platforms and releases for NonStop  include both
 Java 8 and Java 11, customers on NonStop and Linux that are
 Enterprise-focused (and there are MANY) haven't installed Java 11 and have
 no plan to do so  this year or probably even next.  What was the
 penetration number above for Java 11, only 4%?  Expecting a large
 percentage of your customer base to make this move is short-sighted.


>>> We're not expecting them to make a move.  We're changing the default in
>>> the Jenkins Docker images so that users who choose to use the default
>>> Jenkins Docker images will use Java 11 instead of Java 8.  Users that can't
>>> use Docker images (arm32, ppc64, s390x, ia64, riscv) can continue to use
>>> either Java 8 or Java 11 on their platform.  After the change, users that
>>> are running Docker images can change the name of the image they are using
>>> and that will allow them to continue running with Java 8.  Today, if they
>>> run with `docker run --rm -i -t jenkins/jenkins:lts` and 

RE: Using JDK 11 instead of JDK 8 in default docker images

[Bill Honaker]

That is indeed inevitable, but one would hop that it is not likely to be 
imminent.  The last 'push' to change support levels, as I recall, was the 
stronger crypto support added in Java 8, which 'encouraged' companies to move 
to 8 in order to remain interoperable.   Especially given the number of plugins 
and frameworks that build on communications, that change was accelerated.

The hard limit on the older system (as there will be no Java 11 JRE on the 'E'  
platform) will disappear when the vendor's support of the 'E' platform  comes 
to an  end in just a few years.  However I can see the same challenge to us all 
when Java 11 is no longer in vogue.

It's limited in scope, however, to the remoting parts of Jenkins.  It's quite 
an easy recommendation to make that the controller should NOT run on NonStop, 
not just for compatibility but for cost reasons (as the NonStop platform is 
often more expensive to run than Linux distros or Windows servers).

So only the remoting packages are affected.  And the choice of, say, SSH 
features needed could reasonably be limited on a 'Node' basis to only those 
that are implemented on the target (for example, key size, authentication 
method, etc.).

Bill

-Original Message-
From: jenkinsci-dev@googlegroups.com  On Behalf 
Of Matt Sicker
Sent: Wednesday, August 11, 2021 12:37 PM
To: jenkinsci-dev@googlegroups.com
Subject: Re: Using JDK 11 instead of JDK 8 in default docker images

I mean there's a very real chance that regardless of how long Jenkins attempts 
to keep Java 8 compatibility, eventually some dependency it or a key plugin 
uses will stop supporting Java 8 and subsequently publish CVEs that are only 
fixed in the Java 11 version. I don't expect that to happen very soon, but it's 
definitely something to consider in the longer term. The Java 17 release, being 
an LTS one, will encourage some communities to move their base level of Java 
support from Java 8 to 11 (which has already been slowly happening with some 
projects).

On Wed, Aug 11, 2021 at 11:32 AM Bill Honaker  wrote:
>
> Matt,
>
>
>
> Oracle releases Java to the larger OS platforms (Windows, Linux, MacOS, IOS, 
> Android) directly.  However for other platforms (speaking specifically for 
> NonStop), the vendor has to do the deep port themselves and go through their 
> QA process, etc.  They do this with the support of Oracle (under paid license 
> and support), but it’s never going to be fast.  Java 11 has only been 
> released on NonStop for a few years now (not 10).  And there are actually 2  
> different underlying instruction sets.  The currently-sold versions NonStop 
> (‘X’ and ‘V’) run on Xeon processors or in VMs, and Java 11 exists for those. 
>  However, ‘E’ is an Itanium-based platform that is no longer sold but is 
> still supported for Enterprise customers.  It still has 3 years of support 
> remaining.
>
>
>
> I wouldn’t expect Java 17 to be available for NonStop for another 5-10 years.
>
>
>
> Building Java apps with Java 11 that run on an Java 8 RTE is not difficult at 
> all.  Where you may run into issues is with 3rd party packages.  But in the 
> Open Source world it’s at least theoretical that you have the source and can 
> rebuild the class files with the ability to run on Java 8, if the 
> functionality of the package you need is critical.
>
>
>
> Many of the Enterprise customers using NonStop, while not averse to change 
> (otherwise they wouldn’t be in the devops realm), but they are very skeptical 
> about changing things.  Their business critical apps run for years without an 
> outage.  (They use replication  and managed failover to avoid planned 
> outages, for example).  How to reach them and ask?  Those of us that work 
> with the platform do so with various publications and events.
>
>
>
> But the developers that use tools like git and Jenkins actually WILL be the 
> ones that are impacted if Jenkins won’t run (correctly) because the JRE is at 
> Java 8.
>
>
>
> I’ve heard of other platforms where the story is similar but am not an expert 
> on them.
>
>
>
>
>
> From: jenkinsci-dev@googlegroups.com  
> On Behalf Of Matt Sicker
> Sent: Wednesday, August 11, 2021 10:03 AM
> To: jenkinsci-dev@googlegroups.com
> Subject: Re: Using JDK 11 instead of JDK 8 in default docker images
>
>
>
> Plus Java 17 comes out really soon. I can imagine that will inspire more 
> projects to set Java 11 as a baseline. Definitely start planning since most 
> people will probably be affected by some other dependencies well before they 
> hit Jenkins.
>
> Matt Sicker
>
>
>
> On Aug 11, 2021, at 09:18, jn...@cloudbees.com  wrote:
>
> Hi Bill (et al) for those that are running nonstop or the like and have an 
> update / test cycle in the order of 6 months :
>
>
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the 

Jenkins Governance Meeting, August 11, 2021

[Mark Waite]

Today we will have the regular Jenkins Governance meeting.  The meeting 
will start at 7PM UTC, everyone is welcome to participate.

See the agenda draft 

 for 
details.

   - News - Jenkins 2.306 released, 2.302.1 coming soon
   - Request to change the contents of the www.jenkins.io scrolling page 
   (Jumbotron)

If you'd like to add a topic, please suggest it in the Google Doc 

.

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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/faf21772-2feb-4505-86dd-95acf78058cbn%40googlegroups.com.

Re: Using JDK 11 instead of JDK 8 in default docker images

[Matt Sicker]

I mean there's a very real chance that regardless of how long Jenkins
attempts to keep Java 8 compatibility, eventually some dependency it
or a key plugin uses will stop supporting Java 8 and subsequently
publish CVEs that are only fixed in the Java 11 version. I don't
expect that to happen very soon, but it's definitely something to
consider in the longer term. The Java 17 release, being an LTS one,
will encourage some communities to move their base level of Java
support from Java 8 to 11 (which has already been slowly happening
with some projects).

On Wed, Aug 11, 2021 at 11:32 AM Bill Honaker  wrote:
>
> Matt,
>
>
>
> Oracle releases Java to the larger OS platforms (Windows, Linux, MacOS, IOS, 
> Android) directly.  However for other platforms (speaking specifically for 
> NonStop), the vendor has to do the deep port themselves and go through their 
> QA process, etc.  They do this with the support of Oracle (under paid license 
> and support), but it’s never going to be fast.  Java 11 has only been 
> released on NonStop for a few years now (not 10).  And there are actually 2  
> different underlying instruction sets.  The currently-sold versions NonStop 
> (‘X’ and ‘V’) run on Xeon processors or in VMs, and Java 11 exists for those. 
>  However, ‘E’ is an Itanium-based platform that is no longer sold but is 
> still supported for Enterprise customers.  It still has 3 years of support 
> remaining.
>
>
>
> I wouldn’t expect Java 17 to be available for NonStop for another 5-10 years.
>
>
>
> Building Java apps with Java 11 that run on an Java 8 RTE is not difficult at 
> all.  Where you may run into issues is with 3rd party packages.  But in the 
> Open Source world it’s at least theoretical that you have the source and can 
> rebuild the class files with the ability to run on Java 8, if the 
> functionality of the package you need is critical.
>
>
>
> Many of the Enterprise customers using NonStop, while not averse to change 
> (otherwise they wouldn’t be in the devops realm), but they are very skeptical 
> about changing things.  Their business critical apps run for years without an 
> outage.  (They use replication  and managed failover to avoid planned 
> outages, for example).  How to reach them and ask?  Those of us that work 
> with the platform do so with various publications and events.
>
>
>
> But the developers that use tools like git and Jenkins actually WILL be the 
> ones that are impacted if Jenkins won’t run (correctly) because the JRE is at 
> Java 8.
>
>
>
> I’ve heard of other platforms where the story is similar but am not an expert 
> on them.
>
>
>
>
>
> From: jenkinsci-dev@googlegroups.com  On 
> Behalf Of Matt Sicker
> Sent: Wednesday, August 11, 2021 10:03 AM
> To: jenkinsci-dev@googlegroups.com
> Subject: Re: Using JDK 11 instead of JDK 8 in default docker images
>
>
>
> Plus Java 17 comes out really soon. I can imagine that will inspire more 
> projects to set Java 11 as a baseline. Definitely start planning since most 
> people will probably be affected by some other dependencies well before they 
> hit Jenkins.
>
> Matt Sicker
>
>
>
> On Aug 11, 2021, at 09:18, jn...@cloudbees.com  wrote:
>
> Hi Bill (et al) for those that are running nonstop or the like and have an 
> update / test cycle in the order of 6 months :
>
>
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the project 
> will be able to give you all the advance notice you need.
>
>
>
> Jenkins has supported Java11 for a while now, and if there are any specifics 
> from you that cause it not to run we would like to be aware as early as 
> possible (it won;t help you if we find out after the switch has been made and 
> 7 days before a go live)
>
> >  Most of your customers don't spend time reviewing this group.  And many 
> > Enterprise decisionmakers don't participate in Twitter, which leaves the 
> > results of surveys in that platform somewhat questionable.
>
> On that note - where should we announce surveys / things like this - if users 
> are not in the user email / discored or the like how can we reach people to 
> inform them and have them participate?
>
> I also work for a company (CloudBees) that has Jenkins at its core for 
> Enterprise customers, so we have the statistics from these installations as 
> well - so this project is not blind of enterprises (and if a customer wants a 
> version of Jenkins that is supported for 9 months rather than the normal 3 we 
> can probably help you out, and there may be others)
>
>
>
> Regards
>
>
>
> /James
>
> On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com wrote:
>
> Mark,
>
>
>
> Randall had pointed me to this thread.  I admit to only reading the last 
> couple of dozen posts and, based only on that, share my concerns.  I should 
> have spent more time reading the thread, 

Re: Disable job with reason?

['Gavin Mogan' via Jenkins Developers]

> Basically have a need to have it when a job is disabled there's a reason
associated with why.   Also trigger and external system when it is.

This would be a using question, I recommend asking again on
community.jenkins.io or users mailing list

> where do I hook in to create this extension?

I believe disabled is a property on the job itself, as for where/how to
handle a reason, you'd probably want to make a new action with a new http
post handler, which disables the job and job.addAction(yournewclass)
then render that action however/wherever you want.

Gavin


On Wed, Aug 11, 2021 at 7:46 AM Michael Carter 
wrote:

> Basically have a need to have it when a job is disabled there's a reason
> associated with why.   Also trigger and external system when it is.
>
> Is there such a plugin and/or where do I hook in to create this extension?
>
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/47675d76-904f-4318-8c71-e3c338341c84n%40googlegroups.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DutKmr-OuXGwfd_2tqJ-RQ%2BjCve8%3DM7mdztMFur%2BayrWVA%40mail.gmail.com.

RE: Using JDK 11 instead of JDK 8 in default docker images

[Bill Honaker]

Matt,

 

Oracle releases Java to the larger OS platforms (Windows, Linux, MacOS, IOS, 
Android) directly.  However for other platforms (speaking specifically for 
NonStop), the vendor has to do the deep port themselves and go through their QA 
process, etc.  They do this with the support of Oracle (under paid license and 
support), but it’s never going to be fast.  Java 11 has only been released on 
NonStop for a few years now (not 10).  And there are actually 2  different 
underlying instruction sets.  The currently-sold versions NonStop (‘X’ and ‘V’) 
run on Xeon processors or in VMs, and Java 11 exists for those.  However, ‘E’ 
is an Itanium-based platform that is no longer sold but is still supported for 
Enterprise customers.  It still has 3 years of support remaining.  

 

I wouldn’t expect Java 17 to be available for NonStop for another 5-10 years.  

 

Building Java apps with Java 11 that run on an Java 8 RTE is not difficult at 
all.  Where you may run into issues is with 3rd party packages.  But in the 
Open Source world it’s at least theoretical that you have the source and can 
rebuild the class files with the ability to run on Java 8, if the functionality 
of the package you need is critical.

 

Many of the Enterprise customers using NonStop, while not averse to change 
(otherwise they wouldn’t be in the devops realm), but they are very skeptical 
about changing things.  Their business critical apps run for years without an 
outage.  (They use replication  and managed failover to avoid planned outages, 
for example).  How to reach them and ask?  Those of us that work with the 
platform do so with various publications and events. 

 

But the developers that use tools like git and Jenkins actually WILL be the 
ones that are impacted if Jenkins won’t run (correctly) because the JRE is at 
Java 8.

 

I’ve heard of other platforms where the story is similar but am not an expert 
on them.

 

 

From: jenkinsci-dev@googlegroups.com  On Behalf 
Of Matt Sicker
Sent: Wednesday, August 11, 2021 10:03 AM
To: jenkinsci-dev@googlegroups.com
Subject: Re: Using JDK 11 instead of JDK 8 in default docker images

 

Plus Java 17 comes out really soon. I can imagine that will inspire more 
projects to set Java 11 as a baseline. Definitely start planning since most 
people will probably be affected by some other dependencies well before they 
hit Jenkins.

Matt Sicker





On Aug 11, 2021, at 09:18, jn...@cloudbees.com   
mailto:jn...@cloudbees.com> > wrote:

Hi Bill (et al) for those that are running nonstop or the like and have an 
update / test cycle in the order of 6 months :


I would recommend that your customers probably want to start the planning / 
validation to update to Java11 now even if this LTS version still runs on 
Java8.  Java11 is going to happen at some point and I am not sure the project 
will be able to give you all the advance notice you need.

 

Jenkins has supported Java11 for a while now, and if there are any specifics 
from you that cause it not to run we would like to be aware as early as 
possible (it won;t help you if we find out after the switch has been made and 7 
days before a go live)

>  Most of your customers don't spend time reviewing this group.  And many 
> Enterprise decisionmakers don't participate in Twitter, which leaves the 
> results of surveys in that platform somewhat questionable.

On that note - where should we announce surveys / things like this - if users 
are not in the user email / discored or the like how can we reach people to 
inform them and have them participate?

I also work for a company (CloudBees) that has Jenkins at its core for 
Enterprise customers, so we have the statistics from these installations as 
well - so this project is not blind of enterprises (and if a customer wants a 
version of Jenkins that is supported for 9 months rather than the normal 3 we 
can probably help you out, and there may be others) 

 

Regards

 

/James

On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com 
  wrote:

Mark,

 

Randall had pointed me to this thread.  I admit to only reading the last couple 
of dozen posts and, based only on that, share my concerns.  I should have spent 
more time reading the thread, but I was scheduled to do a code walkthrough with 
my customer and took the 'short' path, for which I apologize.

 

Your clarification does seem 100% the right thing to do, and I thank you for 
sharing it.  That's worth much  more than .02$US!

 

And my customers all never need know I ever had this concern, you had it  
covered. :-)

 

Bill

On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:

Thanks for sharing your insights.  Great to have participation in the thread.  
Comments are inline

 

On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:

Similar to Randall (the.n...), I have customers that use NonStop, but they also 
use various distros of Enterprise 

Re: Using JDK 11 instead of JDK 8 in default docker images

[Matt Sicker]

Plus Java 17 comes out really soon. I can imagine that will inspire more 
projects to set Java 11 as a baseline. Definitely start planning since most 
people will probably be affected by some other dependencies well before they 
hit Jenkins.

Matt Sicker

> On Aug 11, 2021, at 09:18, jn...@cloudbees.com  wrote:
> 
> Hi Bill (et al) for those that are running nonstop or the like and have an 
> update / test cycle in the order of 6 months :
> 
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the project 
> will be able to give you all the advance notice you need.
> 
> Jenkins has supported Java11 for a while now, and if there are any specifics 
> from you that cause it not to run we would like to be aware as early as 
> possible (it won;t help you if we find out after the switch has been made and 
> 7 days before a go live)
> 
> >  Most of your customers don't spend time reviewing this group.  And many 
> > Enterprise decisionmakers don't participate in Twitter, which leaves the 
> > results of surveys in that platform somewhat questionable.
> 
> On that note - where should we announce surveys / things like this - if users 
> are not in the user email / discored or the like how can we reach people to 
> inform them and have them participate?
> 
> I also work for a company (CloudBees) that has Jenkins at its core for 
> Enterprise customers, so we have the statistics from these installations as 
> well - so this project is not blind of enterprises (and if a customer wants a 
> version of Jenkins that is supported for 9 months rather than the normal 3 we 
> can probably help you out, and there may be others) 
> 
> Regards
> 
> /James
>> On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com wrote:
>> Mark,
>> 
>> Randall had pointed me to this thread.  I admit to only reading the last 
>> couple of dozen posts and, based only on that, share my concerns.  I should 
>> have spent more time reading the thread, but I was scheduled to do a code 
>> walkthrough with my customer and took the 'short' path, for which I 
>> apologize.
>> 
>> Your clarification does seem 100% the right thing to do, and I thank you for 
>> sharing it.  That's worth much  more than .02$US!
>>  
>> And my customers all never need know I ever had this concern, you had it  
>> covered. :-)
>> 
>> Bill
>>> On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:
>>> Thanks for sharing your insights.  Great to have participation in the 
>>> thread.  Comments are inline
>>> 
 On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:
 Similar to Randall (the.n...), I have customers that use NonStop, but they 
 also use various distros of Enterprise Linux.  Their corporate strategy 
 for software development is to remain on Java 8 for the foreseeable 
 future, primarily due to the JDK  11 licensing mentioned above.  They have 
 a corporate support contract with Oracle to continue to get Java 8 
 updates, so support is not an issue for them.  Shipping a version of 
 Jenkins that won't do 'remoting' on those target platforms should require 
 much longer than 5 months of advance notice, as those customers are on 
 much longer strategic cycles.
 
>>> 
>>> I'm not sure where you're getting the idea that we would be shipping a 
>>> version of Jenkins that won't do 'remoting' on those target platforms.  The 
>>> proposal does not remove Java 8 support.  The proposal does not prevent 
>>> users from running agents or controllers or both with Java 8.  The proposal 
>>> does not change how 'remoting' operates.
>>> 
>>>  
 Even though  the newer platforms and releases for NonStop  include both 
 Java 8 and Java 11, customers on NonStop and Linux that are 
 Enterprise-focused (and there are MANY) haven't installed Java 11 and have 
 no plan to do so  this year or probably even next.  What was the 
 penetration number above for Java 11, only 4%?  Expecting a large 
 percentage of your customer base to make this move is short-sighted.
 
>>> 
>>> We're not expecting them to make a move.  We're changing the default in the 
>>> Jenkins Docker images so that users who choose to use the default Jenkins 
>>> Docker images will use Java 11 instead of Java 8.  Users that can't use 
>>> Docker images (arm32, ppc64, s390x, ia64, riscv) can continue to use either 
>>> Java 8 or Java 11 on their platform.  After the change, users that are 
>>> running Docker images can change the name of the image they are using and 
>>> that will allow them to continue running with Java 8.  Today, if they run 
>>> with `docker run --rm -i -t jenkins/jenkins:lts` and they have a hard 
>>> requirement for Java 8, they will need to run with `docker run --rm -i -t 
>>> jenkins/jenkins:lts-jdk8`.
>>> 
 If Jenkins is to 

Disable job with reason?

[Michael Carter]

Basically have a need to have it when a job is disabled there's a reason 
associated with why.   Also trigger and external system when it is.

Is there such a plugin and/or where do I hook in to create this extension?

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/47675d76-904f-4318-8c71-e3c338341c84n%40googlegroups.com.

Re: Using JDK 11 instead of JDK 8 in default docker images

[jn...@cloudbees.com]

Hi Bill (et al) for those that are running nonstop or the like and have an 
update / test cycle in the order of 6 months :

I would recommend that your customers probably want to start the planning / 
validation to update to Java11 now even if this LTS version still runs on 
Java8.  Java11 is going to happen at some point and I am not sure the 
project will be able to give you all the advance notice you need.

Jenkins has supported Java11 for a while now, and if there are any 
specifics from you that cause it not to run we would like to be aware as 
early as possible (it won;t help you if we find out after the switch has 
been made and 7 days before a go live)

>  Most of your customers don't spend time reviewing this group.  And many 
Enterprise decisionmakers don't participate in Twitter, which leaves the 
results of surveys in that platform somewhat questionable.

On that note - where should we announce surveys / things like this - if 
users are not in the user email / discored or the like how can we reach 
people to inform them and have them participate?

I also work for a company (CloudBees) that has Jenkins at its core for 
Enterprise customers, so we have the statistics from these installations as 
well - so this project is not blind of enterprises (and if a customer wants 
a version of Jenkins that is supported for 9 months rather than the normal 
3 we can probably help you out, and there may be others) 

Regards

/James
On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 bhon...@xid.com wrote:

> Mark,
>
> Randall had pointed me to this thread.  I admit to only reading the last 
> couple of dozen posts and, based only on that, share my concerns.  I should 
> have spent more time reading the thread, but I was scheduled to do a code 
> walkthrough with my customer and took the 'short' path, for which I 
> apologize.
>
> Your clarification does seem 100% the right thing to do, and I thank you 
> for sharing it.  That's worth much  more than .02$US!
>  
> And my customers all never need know I ever had this concern, you had it  
> covered. :-)
>
> Bill
> On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:
>
>> Thanks for sharing your insights.  Great to have participation in the 
>> thread.  Comments are inline
>>
>> On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:
>>
>>> Similar to Randall (the.n...), I have customers that use NonStop, but 
>>> they also use various distros of Enterprise Linux.  Their corporate 
>>> strategy for software development is to remain on Java 8 for the 
>>> foreseeable future, primarily due to the JDK  11 licensing mentioned 
>>> above.  They have a corporate support contract with Oracle to continue to 
>>> get Java 8 updates, so support is not an issue for them.  Shipping a 
>>> version of Jenkins that won't do 'remoting' on those target platforms 
>>> should require much longer than 5 months of advance notice, as those 
>>> customers are on much longer strategic cycles.
>>>
>>>
>> I'm not sure where you're getting the idea that we would be shipping a 
>> version of Jenkins that won't do 'remoting' on those target platforms.  The 
>> proposal does not remove Java 8 support.  The proposal does not prevent 
>> users from running agents or controllers or both with Java 8.  The proposal 
>> does not change how 'remoting' operates.
>>
>>  
>>
>>> Even though  the newer platforms and releases for NonStop  include both 
>>> Java 8 and Java 11, customers on NonStop and Linux that are 
>>> Enterprise-focused (and there are MANY) haven't installed Java 11 and have 
>>> no plan to do so  this year or probably even next.  What was the 
>>> penetration number above for Java 11, only 4%?  Expecting a large 
>>> percentage of your customer base to make this move is short-sighted.
>>>
>>>
>> We're not expecting them to make a move.  We're changing the default in 
>> the Jenkins Docker images so that users who choose to use the default 
>> Jenkins Docker images will use Java 11 instead of Java 8.  Users that can't 
>> use Docker images (arm32, ppc64, s390x, ia64, riscv) can continue to use 
>> either Java 8 or Java 11 on their platform.  After the change, users that 
>> are running Docker images can change the name of the image they are using 
>> and that will allow them to continue running with Java 8.  Today, if they 
>> run with `docker run --rm -i -t jenkins/jenkins:lts` and they have a hard 
>> requirement for Java 8, they will need to run with `docker run --rm -i -t 
>> jenkins/jenkins:lts-jdk8`.
>>
>> If Jenkins is to retain its preferred position in Enterprise 
>>> environments, this decision should be very carefully reconsidered. Most of 
>>> your customers don't spend time reviewing this group.  And many Enterprise 
>>> decisionmakers don't participate in Twitter, which leaves the results of 
>>> surveys in that platform somewhat questionable.  This is not just a 
>>> question of what is easier for the developers of Jenkins, it's also a 
>>> matter of 

Re: Choosing Jenkins September LTS release baseline

[Beatriz Munoz]

James I included into https://github.com/jenkinsci/jenkins/pull/5659 
. This is independent of the 
LTS discussion 
> El 11 ago 2021, a las 11:33, jn...@cloudbees.com  
> escribió:
> 
> https://issues.jenkins.io/browse/JENKINS-66139 
> / 
> https://github.com/jenkinsci/jenkins/pull/5621 
>  that made it into 2.304 
> fixes a bug and should be eligible for backporting (it was missed as the 
> issue was not closed and missing the tag).
> 
> On Wednesday, August 11, 2021 at 10:04:41 AM UTC+1 jn...@cloudbees.com 
>  wrote:
> I do not think that this should go into the LTS.  I would have been a -1 
> earlier on the PR itself had seen the PR but well that bird has flown (and I 
> left a comment in the PR as to why).
> 
> The LTS was selected a while ago, there has been a not insignificant amount 
> of work done in preparation for this.  I do not believe that this PR warrants 
> a backport so late into the process.
> 
> /James
> 
> On Wednesday, August 11, 2021 at 9:44:25 AM UTC+1 bma...@gmail.com 
>  wrote:
> I agree the diff seems reasonably small between 2.302 and 2.303.
> Still, we are re-running our CloudBees testsuite on the 2.303 to assess the 
> impact, if any. Stay tuned.
> 
> Le mer. 11 août 2021 à 10:09, Tim Jacomb > a écrit :
> I think we can switch the baseline to newer? Either way I think it's fine to 
> include the above change.
> 
> On Wed, 11 Aug 2021 at 08:00, Basil Crow > wrote:
> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck > wrote:
> > Core dependency version number semantics means anyone on a weekly release 
> > after the LTS baseline but before the change made it into core regularly, 
> > will not have that API and plugins will fail while appearing compatible.
> 
> Ah right, I hadn't considered that.
> 
> > Given that only dependency updates went into 2.303, there's also an 
> > argument for us to choose that as the new baseline instead of 2.302; 
> > eliminating the above problem entirely without adding a lot of risk through 
> > unproven changes (I would expect commons-compress and spring-security 
> > updates to be safe enough).
> 
> If it isn't too late to switch to 2.303, that sounds ideal to me. I
> can easily update the BOM line. But I don't feel strongly either way.
> 
> -- 
> 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/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.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 jenkinsci-de...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/b9ab65f7-a3fd-4fd4-bb2c-c8aa8ef99ba8n%40googlegroups.com
>  
> .

Beatriz Muñoz Manso
Sr Software 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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CFC18597-C85A-40A9-8B51-1CBD1B4683FE%40cloudbees.com.

Re: Choosing Jenkins September LTS release baseline

[jn...@cloudbees.com]

https://issues.jenkins.io/browse/JENKINS-66139 
/ https://github.com/jenkinsci/jenkins/pull/5621 that made it into 2.304 
fixes a bug and should be eligible for backporting (it was missed as the 
issue was not closed and missing the tag).

On Wednesday, August 11, 2021 at 10:04:41 AM UTC+1 jn...@cloudbees.com 
wrote:

> I do not think that this should go into the LTS.  I would have been a -1 
> earlier on the PR itself had seen the PR but well that bird has flown (and 
> I left a comment in the PR as to why).
>
> The LTS was selected a while ago, there has been a not insignificant 
> amount of work done in preparation for this.  I do not believe that this PR 
> warrants a backport so late into the process.
>
> /James
>
> On Wednesday, August 11, 2021 at 9:44:25 AM UTC+1 bma...@gmail.com wrote:
>
>> I agree the diff seems reasonably small between 2.302 and 2.303.
>> Still, we are re-running our CloudBees testsuite on the 2.303 to assess 
>> the impact, if any. Stay tuned.
>>
>> Le mer. 11 août 2021 à 10:09, Tim Jacomb  a écrit :
>>
>>> I think we can switch the baseline to newer? Either way I think it's 
>>> fine to include the above change.
>>>
>>> On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:
>>>
 On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  
 wrote:
 > Core dependency version number semantics means anyone on a weekly 
 release after the LTS baseline but before the change made it into core 
 regularly, will not have that API and plugins will fail while appearing 
 compatible.

 Ah right, I hadn't considered that.

 > Given that only dependency updates went into 2.303, there's also an 
 argument for us to choose that as the new baseline instead of 2.302; 
 eliminating the above problem entirely without adding a lot of risk 
 through 
 unproven changes (I would expect commons-compress and spring-security 
 updates to be safe enough).

 If it isn't too late to switch to 2.303, that sounds ideal to me. I
 can easily update the BOM line. But I don't feel strongly either way.

 -- 
 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/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b9ab65f7-a3fd-4fd4-bb2c-c8aa8ef99ba8n%40googlegroups.com.

Re: Choosing Jenkins September LTS release baseline

[jn...@cloudbees.com]

I do not think that this should go into the LTS.  I would have been a -1 
earlier on the PR itself had seen the PR but well that bird has flown (and 
I left a comment in the PR as to why).

The LTS was selected a while ago, there has been a not insignificant amount 
of work done in preparation for this.  I do not believe that this PR 
warrants a backport so late into the process.

/James

On Wednesday, August 11, 2021 at 9:44:25 AM UTC+1 bma...@gmail.com wrote:

> I agree the diff seems reasonably small between 2.302 and 2.303.
> Still, we are re-running our CloudBees testsuite on the 2.303 to assess 
> the impact, if any. Stay tuned.
>
> Le mer. 11 août 2021 à 10:09, Tim Jacomb  a écrit :
>
>> I think we can switch the baseline to newer? Either way I think it's fine 
>> to include the above change.
>>
>> On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:
>>
>>> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  
>>> wrote:
>>> > Core dependency version number semantics means anyone on a weekly 
>>> release after the LTS baseline but before the change made it into core 
>>> regularly, will not have that API and plugins will fail while appearing 
>>> compatible.
>>>
>>> Ah right, I hadn't considered that.
>>>
>>> > Given that only dependency updates went into 2.303, there's also an 
>>> argument for us to choose that as the new baseline instead of 2.302; 
>>> eliminating the above problem entirely without adding a lot of risk through 
>>> unproven changes (I would expect commons-compress and spring-security 
>>> updates to be safe enough).
>>>
>>> If it isn't too late to switch to 2.303, that sounds ideal to me. I
>>> can easily update the BOM line. But I don't feel strongly either way.
>>>
>>> -- 
>>> 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/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.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 jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0239ded1-26d4-494b-811a-59853da1b26bn%40googlegroups.com.

Re: Choosing Jenkins September LTS release baseline

[Baptiste Mathus]

I agree the diff seems reasonably small between 2.302 and 2.303.
Still, we are re-running our CloudBees testsuite on the 2.303 to assess the
impact, if any. Stay tuned.

Le mer. 11 août 2021 à 10:09, Tim Jacomb  a écrit :

> I think we can switch the baseline to newer? Either way I think it's fine
> to include the above change.
>
> On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:
>
>> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  wrote:
>> > Core dependency version number semantics means anyone on a weekly
>> release after the LTS baseline but before the change made it into core
>> regularly, will not have that API and plugins will fail while appearing
>> compatible.
>>
>> Ah right, I hadn't considered that.
>>
>> > Given that only dependency updates went into 2.303, there's also an
>> argument for us to choose that as the new baseline instead of 2.302;
>> eliminating the above problem entirely without adding a lot of risk through
>> unproven changes (I would expect commons-compress and spring-security
>> updates to be safe enough).
>>
>> If it isn't too late to switch to 2.303, that sounds ideal to me. I
>> can easily update the BOM line. But I don't feel strongly either way.
>>
>> --
>> 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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5TxKmHxsmjOg_HD7sfJ8LJ1%3DGkwsW_TWOHn7V4K7qnfA%40mail.gmail.com.

Re: Choosing Jenkins September LTS release baseline

[Tim Jacomb]

I think we can switch the baseline to newer? Either way I think it's fine
to include the above change.

On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:

> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  wrote:
> > Core dependency version number semantics means anyone on a weekly
> release after the LTS baseline but before the change made it into core
> regularly, will not have that API and plugins will fail while appearing
> compatible.
>
> Ah right, I hadn't considered that.
>
> > Given that only dependency updates went into 2.303, there's also an
> argument for us to choose that as the new baseline instead of 2.302;
> eliminating the above problem entirely without adding a lot of risk through
> unproven changes (I would expect commons-compress and spring-security
> updates to be safe enough).
>
> If it isn't too late to switch to 2.303, that sounds ideal to me. I
> can easily update the BOM line. But I don't feel strongly either way.
>
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.com.

Re: Choosing Jenkins September LTS release baseline

[Basil Crow]

On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  wrote:
> Core dependency version number semantics means anyone on a weekly release 
> after the LTS baseline but before the change made it into core regularly, 
> will not have that API and plugins will fail while appearing compatible.

Ah right, I hadn't considered that.

> Given that only dependency updates went into 2.303, there's also an argument 
> for us to choose that as the new baseline instead of 2.302; eliminating the 
> above problem entirely without adding a lot of risk through unproven changes 
> (I would expect commons-compress and spring-security updates to be safe 
> enough).

If it isn't too late to switch to 2.303, that sounds ideal to me. I
can easily update the BOM line. But I don't feel strongly either way.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.com.

Re: Choosing Jenkins September LTS release baseline

[Daniel Beck]

On Wed, Aug 11, 2021 at 8:16 AM Basil Crow  wrote:

> Thanks for getting this started! I'd like to propose also adding the
> core API for JENKINS-66001 (to which I just added the "lts-candidate"
> label) from https://github.com/jenkinsci/jenkins/pull/5599 to this LTS
> release. This API is intended to be consumed by the Pipeline plugins,
> and including it in an LTS release will facilitate the release of this
> new functionality in Pipeline. Nothing in core consumes the new API,
> so there is no risk of regression here
>

New APIs are generally not great to backport. Core dependency version
number semantics means anyone on a weekly release after the LTS baseline
but before the change made it into core regularly, will not have that API
and plugins will fail while appearing compatible.

That out of the way, this change made it into 2.304, so there's only one
weekly release the above will apply to (2.303), which is probably safe to
ignore if we deem the change important enough.

Given that only dependency updates went into 2.303, there's also an
argument for us to choose that as the new baseline instead of 2.302;
eliminating the above problem entirely without adding a lot of risk
through unproven changes (I would expect commons-compress and
spring-security updates to be safe enough).

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BZ%3DeTyf9RqNdCwwtAYwV3FYvcMLPwtzEjnmfwgjN%3D9ww%40mail.gmail.com.

Re: Choosing Jenkins September LTS release baseline

[Basil Crow]

Thanks for getting this started! I'd like to propose also adding the
core API for JENKINS-66001 (to which I just added the "lts-candidate"
label) from https://github.com/jenkinsci/jenkins/pull/5599 to this LTS
release. This API is intended to be consumed by the Pipeline plugins,
and including it in an LTS release will facilitate the release of this
new functionality in Pipeline. Nothing in core consumes the new API,
so there is no risk of regression here.

On Tue, Aug 10, 2021 at 5:08 AM Beatriz Munoz  wrote:
>
> Morning!
>
> I created https://github.com/jenkinsci/jenkins/pull/5659 with the possible 
> candidates for tomorrow release candidate LTS. These candidates are:
>
> -  https://issues.jenkins-ci.org/browse/JENKINS-65923  
> (https://github.com/jenkinsci/jenkins/pull/5634)
> -  https://issues.jenkins.io/browse/JENKINS-66177 
> (https://github.com/jenkinsci/jenkins/pull/5628)
> -  https://issues.jenkins.io/browse/JENKINS-66094 
> (https://github.com/jenkinsci/jenkins/pull/5613)
>
> Thanks!!
>
> El 3 ago 2021, a las 9:44, Tim Jacomb  escribió:
>
> Hello
>
> This is sorted now, thanks for the report Bea
>
> On Tue, 3 Aug 2021 at 08:21, Beatriz Munoz  wrote:
>>
>> Morning!
>>
>> I created https://github.com/bmunozm/jenkins/tree/towards-2.302 but I cannot 
>> push it to https://github.com/jenkinsci/jenkins. I need someone with rights 
>> that replace https://github.com/jenkinsci/jenkins/tree/stable-2.302 by 
>> https://github.com/bmunozm/jenkins/tree/towards-2.302 using the name 
>> `stable-2.302` for the branch
>>
>> Thank you so much in advance.
>>
>> El 2 ago 2021, a las 12:50, Daniel Beck  escribió:
>>
>>
>>
>> On Mon, Aug 2, 2021 at 12:35 PM Beatriz Munoz  wrote:
>>>
>>> Hi all
>>>
>>> Looking into next LTS I released something is really strange in branch 
>>> `stable-2.302`. If you compare the branch and the tag `jenkins-2.302` there 
>>> are more than 240 files with changes. As the backports are not done yet, I 
>>> guess the difference should me minimal.
>>>
>>> https://github.com/jenkinsci/jenkins/compare/jenkins-2.302..stable-2.302
>>
>>
>> Looking at https://github.com/jenkinsci/jenkins/commits/stable-2.302 it 
>> seems the branch is based on a weekly intermediate state around 2.298/2.299 
>> (~June 21) + some stuff related to PR#5583, rather than 2.302. The branch 
>> should be deleted and recreated. Besides being the wrong baseline, security 
>> fixes from 2.300 would be missing as well.
>>
>>
>> --
>> 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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BLx0OREhYS5%2BLB7mueyKRN5MDqiZuHFTBZ5ESd7cMgGQ%40mail.gmail.com.
>>
>>
>> Beatriz Muñoz Manso
>> Sr Software 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/5A41AE32-6F20-4C81-A7F1-59AF89548DA6%40cloudbees.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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bid9%3DMKNmpH9yX4qA%3DqxxBYiOJgJy_NDimnwPjUCcD6OuQ%40mail.gmail.com.
>
>
> Beatriz Muñoz Manso
> Sr Software 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/17D03184-C4C1-4725-9619-13D295C49ACF%40cloudbees.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrdKRCLV0vbEwQ5Qs0P_VwpeY0niPOBXjonFhfhB5TTtw%40mail.gmail.com.