On 26 March 2015 at 09:39, James Nord <[email protected]> wrote: > On Wednesday, 25 March 2015 16:33:09 UTC, Jesse Glick wrote: >> >> On Wed, Mar 25, 2015 at 6:53 AM, Stephen Connolly >> <[email protected]> wrote: >> > Which is why I think going for JDK7 now is a better plan than trying to >> jump >> > all the way to JDK8 >> >> Painful as it is, I tend to agree. To be clear, by current LTS policy, >> switching the baseline to Java 8 means that someone whose corporate IT >> supports installation of only Java 7 will not receive even security >> fixes in about three months. (CloudBees customers get an extra nine >> months’ reprieve.) Otherwise they are left to backport for themselves. >> > > But they will have a JDK that won't get security fixes in less time than > this unless they have some commercial support - so I don't get what your > point is here? > > The point is that right now people can get security fixes for JDK7. Thus the code base *right now* cannot abandon JDK7.
The next LTS will be picked from a Jenkins tip set up in the next couple of weeks - i.e. while JDK7 is still "supported for free" by Oracle. This means that the best we can do *before May 2015* is move to JDK7... IOW drop support for the well end of life JDK6. On 1st of May 2015 we move Jenkins HEAD to JDK8 because only JDK8 is supported by Oracle. That means that May's LTS is JDK7 *because it was based off a HEAD version that was released while JDK7 was supported by Oracle* The LTS line after May will thus be JDK8 only. After 1st May 2015, anyone running JDK7 will only be getting JDK security fixes if they have a commercial agreement with Oracle or some other vendor, and thus if they want to continue getting security fixes for the last JDK7 line of Jenkins then they have three options: * Contribute to the community by forming a sub-group in the community that does the back-ports. That sub-group would likely want to ask to be signed up to the security-cert list so that they can coordinate. * Do the back ports themselves in a mad panic on the day the changes are released (i.e. I don't think you'll get on the security-cert private list if you are not contributing to the community in some shape or form, or unless you are providing commercial support for Jenkins) * Pay somebody else to provide the support (somebody who is providing commercial support for Jenkins IMHO should be able to get on the security-cert private list even if they are not contributing to the community... I do not view CloudBees as being special in this regard... my personal belief is that if you are providing Jenkins support or providing Jenkins as a Service, you should be contributing to the security-cert effort as a matter of course. I know KK has reached out to a number of other vendors to try and get them involved) Which option they choose is their business -Stephen > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/bfbcba82-cb58-43b4-a763-77b326662a9b%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/bfbcba82-cb58-43b4-a763-77b326662a9b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwj15gcdd9phhRSMGKVWCtemCN4UVbDVe4UY9xpe-ZAsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
