Nicolas, your logic is not correct in that we only force users to upgrade once.
Just because we would require JDK7 does not mean the user needs to install JDK7 and then JDK8 when we require JDK8. They can (*if their platform supports it*) install JDK8 straight away and run Jenkins compiled for JDK7 on it, so they have only one upgrade. If the platform does not support JDK8 then you save one upgrade - how many people are in this situation is the question that may need answering. Right now the OracleJDK 1.8 is supported on RedHat 5.5+ <http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html> and most other mainstream OSes. On Thursday, 26 March 2015 11:01:32 UTC, nicolas de loof wrote: > > right, so the JDK 7 EOL mostly doesn't match our next LTS, > so as we know a JDK switch will impact users, I suggest we postpone JDK > upgrade to post-may LTS, then can adopt JDK 8 in June so the LTS we will > select in July can be based on it. > > Doing this, we will only enforce jenkins user to upgrade JDK once, and > still can move forward in a reasonable delay. > > 2015-03-26 11:40 GMT+01:00 Stephen Connolly <[email protected] > <javascript:>>: > >> >> On 26 March 2015 at 09:39, James Nord <[email protected] <javascript:>> >> 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] <javascript:>. >>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwj15gcdd9phhRSMGKVWCtemCN4UVbDVe4UY9xpe-ZAsQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwj15gcdd9phhRSMGKVWCtemCN4UVbDVe4UY9xpe-ZAsQ%40mail.gmail.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/19b3df75-2446-459b-9780-9fab229bb5ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
