> > One that is on my mind right now may just barely make it to 1.7 this year. >
> Thus my desire to see a way to get the pending trunk work to people who > are not moving to 1.8 any time soon. We should not hold Lucene back because some companies have arcane upgrade policies. Part of what allows policies like this to continue is the slowness of the ecosystem to update, both support (we already have this) and requirement (what is being proposed). As I said in the original message, we should be ahead of the curve, not the project that is dragging behind. I thought I saw a message go by about a 5x branch the other day, so perhaps > things are already exactly what I am asking for This is one proposed alternative to "solve all the trunk problems" (bwc and java8). I think it is a copout (no offense Robert) to avoid forcing an agreement by the community to move forward. Given how long it is likely to be until 6.0, I am not here to argue that > 6.0 should not require 1.8 But no one knows how long it will be until 5.0 either. Even after 5.0 is released, whenever that may be, if there are those in the community that want to stretch life out of the 4x branch on java 7, that is their prerogative. I think the question here is, should trunk be the "blazing forefront of development?" I think it should be, and it seems like many others agree. We should not limit what is possible in trunk because corporate overlords are afraid of change. On Fri, Sep 12, 2014 at 1:24 PM, Benson Margulies <[email protected]> wrote: > > > On Fri, Sep 12, 2014 at 3:35 PM, Robert Muir <[email protected]> wrote: > >> On Fri, Sep 12, 2014 at 3:31 PM, Chris Hostetter >> <[email protected]> wrote: >> > >> > b) that your argument against benson's claims seemed missleading: just >> > because Oracle is EOLing doesn't mean people won't be using OpenJDK; >> even >> > if they are using Oracle's JDK, if they are large comercial >> organizations >> > they might pay oracle to keep using it for a long time. >> > >> >> Its not misleading at all, its being practical. If people want to use >> old jvm versions, good for them. But if they open a corruption bug >> with one of these "commercial" versions, then my only choice is to >> close as "wont fix". So they might as well just use an old lucene >> version, too. >> > > Here's what I know. Over the last few years, the large entities my > employer sells to have been very slow to move to new Java versions. Why? I > dunno, maybe all of them have Mordac working there. Do they pay for > security fixes from Oracle? Or do they just stick their heads in the sand? > I can't tell you. One that is on my mind right now may just barely make it > to 1.7 this year. > > We (meaning this project, not my employer) generally require that > 'significant' changes go into major releases. So, that ties together the > JVM version and these changes. Thus my desire to see a way to get the > pending trunk work to people who are not moving to 1.8 any time soon. An > alternative would be to have a different policy for what can go into a 4.x. > I thought I saw a message go by about a 5x branch the other day, so perhaps > things are already exactly what I am asking for, and I apologize for the > noise. Given how long it is likely to be until 6.0, I am not here to argue > that 6.0 should not require 1.8. I like a nice lambda expression as well as > the next guy. > > > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
