The underlying question is indeed to determine project rules considering supported runtime
1. Support the current and previous verions of the Oracle JDK 2. Support the JDKs that Oracle support 3. do nothing and stick with Java6 until 2020. We already decide to move from 1.5 to 6, and this had some impacts on existing installation, but afaik there's not so much people stuck on jenkins 1.519 ! About upgrade warning, we had Can offer a page comparable to https://wiki.jenkins-ci.org/display/JENKINS/Java+5+Compatibility Requirement to run Java 7 will force some users to upgrade infra, so we already can prepare for complains. As I don't like to receive complains, I'd prefer to upgrade to a JDK which offer actual new programmation options, not just new filesystem API (that we use via XMLFile anyway) so I vote for option 2 2015-03-25 12:45 GMT+01:00 James Nord <[email protected]>: > I didn't mean to kick up this much of a shit storm! > > People have their opinions but we need to move forward to reach a decision > of which there is not one solution that meets everyone's requirements. > > What is the next steps here? > > - Do we vote on the following options: > 1. Support the current and previous verions of the Oracle JDK > 2. Support the JDKs that Oracle support > 3. do nothing and stick with Java6. > - Is this something for the governance board to decide at the next > meeting? > > /James > > On Wednesday, 25 March 2015 10:53:31 UTC, Stephen Connolly wrote: >> >> >> >> On 25 March 2015 at 09:20, Nigel Magnay <[email protected]> wrote: >> >>> >>>> >>>> JDK7 is end of life after April 2015, so in May 2015 if we pick the >>>> second model then we would be JDK8.... but the LTS released in late April >>>> will have been JDK7 and JDK8... as technically only at then end of April is >>>> JDK7 EOL. >>>> >>>> The advantage of the second model is that the July LTS will be JDK8 >>>> >>>> >>> So it could be there's some confusion around "LTS", as the wiki says >>> it follows the ubuntu model, but is it really the same? >>> >> >> No I don't think it is even close to the same >> >>> >>> I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, >>> after which if I want a fix, I'll have to flip to 15.04 (There's an >>> overlap). >>> >>> If I want stability, I pick an LTS version (released every 2 years) - >>> 14.04 LTS - which is supported for *5 years. *It gets no new features >>> in that time, but it does receive updates (indeed we're up to 14.04.2 >>> already). >>> >>> So ubuntu is a release every 6 months, an LTS release every 2 years, >>> with LTS 'support' for 5 years. >>> >>> Jenkins is a release ~every week, an LTS release every 12 weeks, with >>> LTS 'support' for 12 weeks. >>> >> >> That is all that the community has stepped up to deliver. I have no issue >> if the community wants to put effort into maintaining older LTS lines in >> addition to the current LTS, but that is something that the community needs >> to decide. >> >> >>> >>> 12 weeks seems like a very short period of 'support'. Trying to put >>> myself in the shoes of 'corporate IT world', isn't that saying that if I >>> build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks >>> grace before the possibility that a security fix might mean I need to >>> change my JDK ? >>> >>> >> The 'corporate IT world' would really want a 10 year cycle if it could >> get it ;-) >> >> >>> Now - I am perfectly comfortable with that (indeed we step our >>> environment to match the Jenkins LTS editions), but I can see that a >>> side-effect might be those with conservative environments trying hard to >>> make sure that when the 'version with the fix' comes around, basically >>> trying torpedo JDK8 or anything else. >>> >> >> Which is why I think going for JDK7 now is a better plan than trying to >> jump all the way to JDK8 >> >> >>> >>> I'm also perfectly comfortable with the possibility that if you need >>> Jenkins 1.xxx.(n>3), then you obtain those by either contributing the >>> backporting effort yourself, or having a maintenance contract with >>> Cloudbees|A.N.Other that does it for you. >>> >> >>> >>> >>> >>> >>> >>> >>> -- >>> 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/CAPYP83ROco9JLBT8Vthi3YEpNEjLW >>> QtqxkdvjiWzaJPp28u0bg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%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/308a1894-e1df-4c3f-b43e-19c2e5133399%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/308a1894-e1df-4c3f-b43e-19c2e5133399%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/CANMVJzmc5%3D_vxzNR9jrEN0aMJvCZkW%3D7nnWWQ%3DMuByX7T6hDzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
