[RESULT][VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Question for vote was Can the next version major version of a project require Java6? (i.e. drop Java 1.5) Results on binding votes: Christian Grobmeier +1 Gary Gregory +1 Henri Biestro +1 James Carman +1 Jorg Shaible +1 Luc Maisonobe +1 Simone Tripodi +1 Ralph Goers +1 No -1 or 0. Thanks you all for your time, Best regards Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RESULT-VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4176593p4176593.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I guess your +1 does not apply to the vote. :-) And to be honest, javax.script is implemented by org.apache.bsf 3.1 which runs on Java 1.5... Nevertheless, the fair point that has been made by Matt later in this thread is that Commons is a do-ocracy; if someone badly needs a component in Java 1.5, nothing prevents him from contributing that backport from Java6 code. Accepting this and respecting the will of many would be quite a step forward since it means Commons would cease forcing people to contribute new projects/major-versions on an EOLed platform - for which they have rightfully no interest for. IMHO, the Java 1.5 release rule, besides forcing the installation/maintenance cost of the dev platform for contributors, nurtures the perception that Commons is just an unattractive set of obsolete components. And besides, nothing in the Commons charter states that components must support 2 major versions old JDKs; stability and quality should not equate to obsolescence. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4168607.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
It's a matter or balance, if you just want to have fun you can build a component based on OpenJDK 8 with lots of lambda, but nobody will use it today. And I doubt it will attract new contributors. If avoiding trivial things like String.isEmpty() can widen the audience, and thus the potential contributors, then I'm willing to develop with that constraint. I regret you don't seem to share this point of view, but I can't force you to accept it, and I won't prevent you from enjoying the new APIs. Emmanuel Bourg smime.p7s Description: Signature cryptographique S/MIME
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I respect your point of view but it is really hard to attract new contributors when we first state they MUST code with JDK 1.5. And again, if the need for a Java 1.5 backport is proven - rather than imposed by default - , it's always possible to people interested in it to contribute (and/or ask). Plus I really suspect that for edge projects, there is absolutely no audience widening in supporting Java 1.5. Regards, Henrib PS: it would be pretty interesting to know which JDK is actually deployed within enterprises by segment/size. All customers we see - mostly Oracle customers as well - now run Java6. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4169631.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Wed, Dec 7, 2011 at 11:46 AM, henrib hen...@apache.org wrote: I respect your point of view but it is really hard to attract new contributors when we first state they MUST code with JDK 1.5. And again, if the need for a Java 1.5 backport is proven - rather than imposed by default - , it's always possible to people interested in it to contribute (and/or ask). Plus I really suspect that for edge projects, there is absolutely no audience widening in supporting Java 1.5. Regards, Henrib PS: it would be pretty interesting to know which JDK is actually deployed within enterprises by segment/size. All customers we see - mostly Oracle customers as well - now run Java6. FWIW, at work, we went from Java 1.4.2 directly to 1.6 years ago. We changed the platform requirement for our server and tool and that was that. If you want to use the latest and greatest of our wares, you need Java 6. We do use JAXB, scripting and so on, so it's a lot more than String#isEmpty() ;) Gary -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4169631.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Matt Benson-2 wrote Maybe the right approach is to start with Java 6, then whoever likes to can investigate how much work it would take to restore Java 5 compatibility. Seems like a reasonable proposal to me; it means Java 1.5 is a nice to have feature - not a must have - feature as it currently stands. If someone needs a Java 1.5 backport, he can contribute to the project by doing so. Do-ocracy at work. Fair enough? Cheers Henrib PS: may be at the process/Commons level, we could introduce another category for of our projects. Instead of the current 3 Proper, Sandbox, Dormant, something like Stable (1.5-able), Proper, Sandox, Dormant or Modern, Proper (1.5 able), Sandbox, Dormant. So new versions can go modern till the need arise a contribution is made for a stable version. Just a thought... -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4164066.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Tue, Dec 6, 2011 at 10:45 AM, henrib hen...@apache.org wrote: Matt Benson-2 wrote Maybe the right approach is to start with Java 6, then whoever likes to can investigate how much work it would take to restore Java 5 compatibility. Seems like a reasonable proposal to me; it means Java 1.5 is a nice to have feature - not a must have - feature as it currently stands. If someone needs a Java 1.5 backport, he can contribute to the project by doing so. Do-ocracy at work. Fair enough? +1 Exactly that is what I wanted to express. Looks like I can't express very well. Cheers Christian Cheers Henrib PS: may be at the process/Commons level, we could introduce another category for of our projects. Instead of the current 3 Proper, Sandbox, Dormant, something like Stable (1.5-able), Proper, Sandox, Dormant or Modern, Proper (1.5 able), Sandbox, Dormant. So new versions can go modern till the need arise a contribution is made for a stable version. Just a thought... -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4164066.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Le 05/12/2011 16:14, Christian Grobmeier a écrit : [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement +1 I think the maintainers of a component can decide on their own which jdk they want to support. If you want to support a newer Java with the next big major version of JEXL I give you my +1. For me a major version is allowed to break old rules and create new ones. Agreed. PS: Is there a process to formally move a project from Commons to elsewhere within Apache? There is a general process for moving to attic, but I don't think this is what you want. I think there is also a general process to become a TLP. This is exactly what commons did some years ago, coming from Jakarta. Luc What exactly do you mean? Make JEXL a top level project or move JEXL to another toplevel project? Or something completley different? To move JEXL out of here, i think you should make up a (good) proposal and vote on this list. I can imagine it would go to the incubator to build up an community. Anyway I tend to think a component should have a pretty good size to stand on its own. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
+1, move to jdk6 (go to jdk7 if you want :) On Dec 5, 2011 9:17 AM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Le 05/12/2011 20:22, Matt Benson a écrit : I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. +1, this summarize pretty well my opinion. It's not worth requiring Java 6 if you only use String.isEmpty(). But if you need javax.script that's a very good reason to upgrade. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Salut Henri, if you need the Java6 APIs to provide a fresh new set of APIs to JEXL users, I would be +1. We recently accepted Java6 in Apache Cocoon since Oracle announced Java 5 SE EOL (End Of Life) since 2009. Anyway I would to point you to a message in the ASF Tika ML[1] where describing the pros and cons about moving to Java6 - I wonder how many users would still require Java4/5 to run JEXL. Break a leg, all the best, Simo [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
[+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement I think the maintainers of a component can decide on their own which jdk they want to support. If you want to support a newer Java with the next big major version of JEXL I give you my +1. For me a major version is allowed to break old rules and create new ones. PS: Is there a process to formally move a project from Commons to elsewhere within Apache? What exactly do you mean? Make JEXL a top level project or move JEXL to another toplevel project? Or something completley different? To move JEXL out of here, i think you should make up a (good) proposal and vote on this list. I can imagine it would go to the incubator to build up an community. Anyway I tend to think a component should have a pretty good size to stand on its own. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Easy one: +1. Gary On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement I think the maintainers of a component can decide on their own which jdk they want to support. If you want to support a newer Java with the next big major version of JEXL I give you my +1. For me a major version is allowed to break old rules and create new ones. PS: Is there a process to formally move a project from Commons to elsewhere within Apache? What exactly do you mean? Make JEXL a top level project or move JEXL to another toplevel project? Or something completley different? To move JEXL out of here, i think you should make up a (good) proposal and vote on this list. I can imagine it would go to the incubator to build up an community. Anyway I tend to think a component should have a pretty good size to stand on its own. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement I think the maintainers of a component can decide on their own which jdk they want to support. If you want to support a newer Java with the next big major version of JEXL I give you my +1. For me a major version is allowed to break old rules and create new ones. I agree. Gary PS: Is there a process to formally move a project from Commons to elsewhere within Apache? What exactly do you mean? Make JEXL a top level project or move JEXL to another toplevel project? Or something completley different? To move JEXL out of here, i think you should make up a (good) proposal and vote on this list. I can imagine it would go to the incubator to build up an community. Anyway I tend to think a component should have a pretty good size to stand on its own. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote: Salut Henri, if you need the Java6 APIs to provide a fresh new set of APIs to JEXL users, I would be +1. We recently accepted Java6 in Apache Cocoon since Oracle announced Java 5 SE EOL (End Of Life) since 2009. Cocoon is a slightly different case, as it's probably not embedded in other components as much as Commons components are. Anyway I would to point you to a message in the ASF Tika ML[1] where describing the pros and cons about moving to Java6 - I wonder how many users would still require Java4/5 to run JEXL. Exactly - but I'm not sure we'll find that out by asking on the developer list, where one would expect people to install the new versions of Java as they come out. If the argument is that Jexl users don't need it to run on Java 1.5, then a better place to ask the question might be the user list. Break a leg, all the best, Simo [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 4:31 PM, Gary Gregory garydgreg...@gmail.com wrote: On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement I think the maintainers of a component can decide on their own which jdk they want to support. If you want to support a newer Java with the next big major version of JEXL I give you my +1. For me a major version is allowed to break old rules and create new ones. I agree. Gary me too, that's why I started working on Digester3 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 4:43 PM, sebb seb...@gmail.com wrote: On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote: Salut Henri, if you need the Java6 APIs to provide a fresh new set of APIs to JEXL users, I would be +1. We recently accepted Java6 in Apache Cocoon since Oracle announced Java 5 SE EOL (End Of Life) since 2009. Cocoon is a slightly different case, as it's probably not embedded in other components as much as Commons components are. Java 5 EOL 2009? Thats 2 years. I mean, we can still make releases of JEXL 2.x and fix bugs, while the new JEXL 3.x line supports a newer Java and creates new features. I think this is how most software vendors do it. Make the old line bugfix only and concentrate on the new line with current platform. Anyway I would to point you to a message in the ASF Tika ML[1] where describing the pros and cons about moving to Java6 - I wonder how many users would still require Java4/5 to run JEXL. Exactly - but I'm not sure we'll find that out by asking on the developer list, where one would expect people to install the new versions of Java as they come out. If the argument is that Jexl users don't need it to run on Java 1.5, then a better place to ask the question might be the user list. Jexl users in need of 1.5 can still use the 2.x line. Where is the problem? If we always ask about every of our steps we will never go forward. Cheers Break a leg, all the best, Simo [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Forgot to add the vote will close in 72 hours, as per-usual rules. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161054.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 5, 2011 at 4:43 PM, sebb seb...@gmail.com wrote: On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote: Salut Henri, if you need the Java6 APIs to provide a fresh new set of APIs to JEXL users, I would be +1. We recently accepted Java6 in Apache Cocoon since Oracle announced Java 5 SE EOL (End Of Life) since 2009. Cocoon is a slightly different case, as it's probably not embedded in other components as much as Commons components are. nope, new Cocoon3 has small commons components as well that allow users embed it in a commons-xxx style, take a look at Christian's experience on his blog post[1] Anyway I would to point you to a message in the ASF Tika ML[1] where describing the pros and cons about moving to Java6 - I wonder how many users would still require Java4/5 to run JEXL. Exactly - but I'm not sure we'll find that out by asking on the developer list, where one would expect people to install the new versions of Java as they come out. If the argument is that Jexl users don't need it to run on Java 1.5, then a better place to ask the question might be the user list. agreed, but I guess HenriB concern is on dev side as well, the implicit question sounds clear to me: is there any objection in the dev community? -Simo [1] http://www.grobmeier.de/create-pdf-cocoon-3-struts-2-15112011.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
+1 to the proposal. As for moving out of commons I would expect that it would require a vote of the Commons PMC with approval from the board. I don't know why it would need to go through the incubator since it would have already performed releases here, its IP would already be cleared and presumably we would only make the proposal if it already had a community of its own. Ralph On Mon, Dec 5, 2011 at 6:17 AM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On 5 December 2011 16:46, henrib hen...@apache.org wrote: You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? That is not a question I can answer, because it's not a simple dichotomy (if that's the correct word). It's not my view that all Commons components have to remain on 1.5 until no-one else is using that release. Nor is it my view that all Commons components should immediately be able to switch to 1.6. My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. I've yet to see that argument put forward; nor has anyone produced evidence that Java 1.5 is not still being used in production across the user base. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 6:44 PM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: +1 to the proposal. As for moving out of commons I would expect that it would require a vote of the Commons PMC with approval from the board. I don't know why it would need to go through the incubator since it would have already performed releases here, its IP would already be cleared and presumably we would only make the proposal if it already had a community of its own. I said it only because of the community building aspect. A new tld would be required and a working PMC must be setup. If this is would be clear from the beginning I agree. Actually if this step would be required, I would try to avoid the incubator as much as I can Ralph On Mon, Dec 5, 2011 at 6:17 AM, henrib hen...@apache.org wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 6:51 PM, sebb seb...@gmail.com wrote: On 5 December 2011 16:46, henrib hen...@apache.org wrote: You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? That is not a question I can answer, because it's not a simple dichotomy (if that's the correct word). It's not my view that all Commons components have to remain on 1.5 until no-one else is using that release. Nor is it my view that all Commons components should immediately be able to switch to 1.6. My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. I've yet to see that argument put forward; nor has anyone produced evidence that Java 1.5 is not still being used in production across the user base. Hey what is wrong with doing jexl3 with Java 6? Why do we need to satisfy to use current technology (guess its already j7 out there)? I mean, the proposal is to upgrade the requirements with a version bump. What is the problem with: - Jexl 2 going maintenance and bugfix mode only, using j5 - Jexl 3 going to have j6 (to the joy of its developers) and doing all the new fancy stuff I do not think we have to clarify why we go to j6, we have to clarify why we still stick to j5 when we do a major version bump. Probably there is need for j5 software - these users can benefit from jexl2. If maintenance mode is not enough I ask myself why we don't still support Java 1.4. I mean, recently I saw it live (guess, at a bank). Imho Commons must not always be the most conservative place ever. We should progress a little more or after all we have only the banks as users, because the modern guys go with all that modern stuff. Of course if you volunteer to migrate all the jexl3 things to jexl2, please go ahead and do it. But this should not force Henri to develop in j6. I mean one team, one dream, but how can you attract new developers with java5 nowadays? Cheers -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161571.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
FWIW, I have been planning on starting work on vfs3 when I finish up with some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file support, so vfs3 will be slimmed down to just provide implementations. Ralph On Mon, Dec 5, 2011 at 9:51 AM, sebb seb...@gmail.com wrote: On 5 December 2011 16:46, henrib hen...@apache.org wrote: You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? That is not a question I can answer, because it's not a simple dichotomy (if that's the correct word). It's not my view that all Commons components have to remain on 1.5 until no-one else is using that release. Nor is it my view that all Commons components should immediately be able to switch to 1.6. My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. I've yet to see that argument put forward; nor has anyone produced evidence that Java 1.5 is not still being used in production across the user base. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On 5 December 2011 18:30, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: FWIW, I have been planning on starting work on vfs3 when I finish up with some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file support, so vfs3 will be slimmed down to just provide implementations. That's again a bit different. VFS3 will effectively then be a different component, addressing a completely different user base. Ralph On Mon, Dec 5, 2011 at 9:51 AM, sebb seb...@gmail.com wrote: On 5 December 2011 16:46, henrib hen...@apache.org wrote: You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? That is not a question I can answer, because it's not a simple dichotomy (if that's the correct word). It's not my view that all Commons components have to remain on 1.5 until no-one else is using that release. Nor is it my view that all Commons components should immediately be able to switch to 1.6. My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. I've yet to see that argument put forward; nor has anyone produced evidence that Java 1.5 is not still being used in production across the user base. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But even if it were the case, you'd still argue for us to continue using IE6... -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161736.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all committers are gone away or the library is the outdated people get some fresher stuff (Collections vs Guava)? If Henri is the opinion that people should use jdk6 he should be allowed to create such a version and call it Jexl3. If you want to keep a jdk5 version, you are of course allowed to support that one. Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all committers are gone away or the library is the outdated people get some fresher stuff (Collections vs Guava)? If Henri is the opinion that people should use jdk6 he should be allowed to create such a version and call it Jexl3. If you want to keep a jdk5 version, you are of course allowed to support that one. Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Matt Benson-2 wrote ... maybe it's worth that tiny bit of extra pain to reach that slightly larger audience... It is not a tiny bit when you accumulate it; and JEXL3 would not reach a larger audience because it allows deployment on Java 1.5. This is a wrongly imposed cost with no benefit. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161848.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all committers are gone away or the library is the outdated people get some fresher stuff (Collections vs Guava)? If Henri is the opinion that people should use jdk6 he should be allowed to create such a version and call it Jexl3. If you want to keep a jdk5 version, you are of course allowed to support that one. Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On 5 December 2011 19:01, henrib hen...@apache.org wrote: sebb-2-2 wrote Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But even if it were the case, you'd still argue for us to continue using IE6... No, I would not; that's an end-user product. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161736.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote But even if it were the case, you'd still argue for us to continue using IE6... No, I would not; that's an end-user product. I see it as the worst web app client platform... Even on that, we can't agree! (sorry, couldn't resist :-)...) -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161935.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. I agree that the developers of a component should do as they [collectively] please. However, in the case of [jexl] it appears that Seb is interested in the development of this component. He may continue to be interested in the development of a v3.x of [jexl]. Now we don't have as clear-cut a case of do-ocracy and henrib just doing what he pleases anymore, because he has to do instead as near as he can get to what he pleases while still functioning in a consensus-based manner. A possible sequence of events: - henrib proposes that [jexl] include feature X, using feature Y from Java 6, thus justifying this minimum version. Assuming the community doesn't vote down the feature on its own merits, Java 6 it is. - sebb can then come along say, hey, I know we agreed on feature X, but I can put in 4 hours of work or create a new Commons component to reimplement feature Y, and now Java 5 users can also benefit from [jexl] 3! Assuming someone else is willing to do the *actual* work required to keep Java 5 compatibility, are you really going to spend time and energy fighting for interface @Overrides? Obviously there would probably be some point at which Seb in this example would say, sure, I could reimplement feature Y, but it's going to take ten hours, twenty hours. Not worth it; have your Java 6! This is the way I see our community as having to function. Matt Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all committers are gone away or the library is the outdated people get some fresher stuff (Collections vs Guava)? If Henri is the opinion that people should use jdk6 he should be allowed to create such a version and call it Jexl3. If you want to keep a jdk5 version, you are of course allowed to support that one. Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote: On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. I agree that the developers of a component should do as they [collectively] please. However, in the case of [jexl] it appears that Seb is interested in the development of this component. He may continue to be interested in the development of a v3.x of [jexl]. Now we don't have as clear-cut a case of do-ocracy and henrib just doing what he pleases anymore, because he has to do instead as near as he can get to what he pleases while still functioning in a consensus-based manner. A possible sequence of events: - henrib proposes that [jexl] include feature X, using feature Y from Java 6, thus justifying this minimum version. Assuming the community doesn't vote down the feature on its own merits, Java 6 it is. - sebb can then come along say, hey, I know we agreed on feature X, but I can put in 4 hours of work or create a new Commons component to reimplement feature Y, and now Java 5 users can also benefit from [jexl] 3! Assuming someone else is willing to do the *actual* work required to keep Java 5 compatibility, are you really going to spend time and energy fighting for interface @Overrides? Obviously there would probably be some point at which Seb in this example would say, sure, I could reimplement feature Y, but it's going to take ten hours, twenty hours. Not worth it; have your Java 6! This is the way I see our community as having to function. With just 2 committers on a component, is not really easy to get an consens when both have different opinions. What now? Henri needs to wait until Sebb gives up java5. ... Christian Matt Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all committers are gone away or the library is the outdated people get some fresher stuff (Collections vs Guava)? If Henri is the opinion that people should use jdk6 he should be allowed to create such a version and call it Jexl3. If you want to keep a jdk5 version, you are of course allowed to support that one. Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Hi Henri, henrib wrote: Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). As a rule of thumb: Do not drop binary compatibility without a really good reason. We were really glad when some of our major customers finally dropped Java 1.4 two years ago, long after its EOL. It is really not uncommon for big players to stay way behind especially in financial business. However ... if you make a complete redesign of the API, that will break compatibility in large parts anyway, it is IMHO also fine to rely on the latest Java version. JEXL 2.x will not vanish and nobody is stopped from creating a maintenance release. So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care +1 Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? The problem of deep dependency conflicts will not suddenly vanish though ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
henrib wrote: sebb-2-2 wrote But even if it were the case, you'd still argue for us to continue using IE6... No, I would not; that's an end-user product. I see it as the worst web app client platform... Even on that, we can't agree! (sorry, couldn't resist :-)...) ... and you know what? One of our major customers finally (!!!) did an upgrade *last month*. This *is* a typical situation in large companies, where a software upgrade means to roll out software to 100'000 computers. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 5:13 PM, Christian Grobmeier grobme...@gmail.comwrote: On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote: On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. I agree that the developers of a component should do as they [collectively] please. However, in the case of [jexl] it appears that Seb is interested in the development of this component. He may continue to be interested in the development of a v3.x of [jexl]. Now we don't have as clear-cut a case of do-ocracy and henrib just doing what he pleases anymore, because he has to do instead as near as he can get to what he pleases while still functioning in a consensus-based manner. A possible sequence of events: - henrib proposes that [jexl] include feature X, using feature Y from Java 6, thus justifying this minimum version. Assuming the community doesn't vote down the feature on its own merits, Java 6 it is. - sebb can then come along say, hey, I know we agreed on feature X, but I can put in 4 hours of work or create a new Commons component to reimplement feature Y, and now Java 5 users can also benefit from [jexl] 3! Assuming someone else is willing to do the *actual* work required to keep Java 5 compatibility, are you really going to spend time and energy fighting for interface @Overrides? Obviously there would probably be some point at which Seb in this example would say, sure, I could reimplement feature Y, but it's going to take ten hours, twenty hours. Not worth it; have your Java 6! This is the way I see our community as having to function. With just 2 committers on a component, is not really easy to get an consens when both have different opinions. What now? Henri needs to wait until Sebb gives up java5. No one has veto power here. We're all reasonable folks. Well, I'd like to think I am. Most of us are passionate and opinionated. That a good thing. If you work towards a .jexl3 Java 6 release and get the votes to get an RC out, I won't and can't stop you. Actually, I'm all for it :) Gary ... Christian Matt Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But that is a separate issue. No it is not. It seems you ignore my idea on having jexl2 in maintenance mode, but this is actually what MS did with Win XP. Now they don't support it. I ask myself, why do we need to support outdated jdks until all
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote: On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. I agree that the developers of a component should do as they [collectively] please. However, in the case of [jexl] it appears that Seb is interested in the development of this component. He may continue to be interested in the development of a v3.x of [jexl]. Now we don't have as clear-cut a case of do-ocracy and henrib just doing what he pleases anymore, because he has to do instead as near as he can get to what he pleases while still functioning in a consensus-based manner. A possible sequence of events: - henrib proposes that [jexl] include feature X, using feature Y from Java 6, thus justifying this minimum version. Assuming the community doesn't vote down the feature on its own merits, Java 6 it is. - sebb can then come along say, hey, I know we agreed on feature X, but I can put in 4 hours of work or create a new Commons component to reimplement feature Y, and now Java 5 users can also benefit from [jexl] 3! Assuming someone else is willing to do the *actual* work required to keep Java 5 compatibility, are you really going to spend time and energy fighting for interface @Overrides? Obviously there would probably be some point at which Seb in this example would say, sure, I could reimplement feature Y, but it's going to take ten hours, twenty hours. Not worth it; have your Java 6! This is the way I see our community as having to function. With just 2 committers on a component, is not really easy to get an consens when both have different opinions. What now? Henri needs to wait until Sebb gives up java5. I don't know what to say. Finding consensus is part of The Apache Way. I guess this means all concerned parties should try and be reasonable and remember that this is a do-ocracy. If Seb wants to make the contributions that will keep [jexl] 3x compatible with 1.5, I don't see that this should inconvenience Henri B. to the point that he should rather work elsewhere. Again, when the burden of maintaining compatibility becomes too great, it will be obviously time to move to Java 6. On the other hand, how long will an API redesign take? Maybe the right approach is to start with Java 6, then whoever likes to can investigate how much work it would take to restore Java 5 compatibility. This could even be done with multiple mvn modules. Matt ... Christian Matt Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I'm confused. Is this a vote thread or a discussion thread? So far I've only seen +1 votes but I may have missed others with all the noise. Ralph On Dec 5, 2011, at 2:45 PM, Matt Benson wrote: On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote: On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote: I think all that Sebastian is saying is something like if you can create your new, cool API and the only things you really miss from Java 6 are @Override on interface implementation methods and ServiceLoader, for example, maybe it's worth that tiny bit of extra pain to reach that slightly larger audience. We all feel frustrated from time to time working in the community setting; I've been there myself, but I don't think Seb is just trying to be a killjoy just for the hell of it. Yes, you might be right on this interpretation. As long as there a volunteers for maintaining jexl2 on j5 setting, I am fine with keeping j5 for it. To be clear, I am not saying we kill jexl2 today or quit jdk5 support for jexl2. But we should not make it a policy to start a new, major version with the lowest JDK version possible when the actual maintainers would like to use a current platform - this needs no discussion imho, they should simply do as they please. I agree that the developers of a component should do as they [collectively] please. However, in the case of [jexl] it appears that Seb is interested in the development of this component. He may continue to be interested in the development of a v3.x of [jexl]. Now we don't have as clear-cut a case of do-ocracy and henrib just doing what he pleases anymore, because he has to do instead as near as he can get to what he pleases while still functioning in a consensus-based manner. A possible sequence of events: - henrib proposes that [jexl] include feature X, using feature Y from Java 6, thus justifying this minimum version. Assuming the community doesn't vote down the feature on its own merits, Java 6 it is. - sebb can then come along say, hey, I know we agreed on feature X, but I can put in 4 hours of work or create a new Commons component to reimplement feature Y, and now Java 5 users can also benefit from [jexl] 3! Assuming someone else is willing to do the *actual* work required to keep Java 5 compatibility, are you really going to spend time and energy fighting for interface @Overrides? Obviously there would probably be some point at which Seb in this example would say, sure, I could reimplement feature Y, but it's going to take ten hours, twenty hours. Not worth it; have your Java 6! This is the way I see our community as having to function. With just 2 committers on a component, is not really easy to get an consens when both have different opinions. What now? Henri needs to wait until Sebb gives up java5. I don't know what to say. Finding consensus is part of The Apache Way. I guess this means all concerned parties should try and be reasonable and remember that this is a do-ocracy. If Seb wants to make the contributions that will keep [jexl] 3x compatible with 1.5, I don't see that this should inconvenience Henri B. to the point that he should rather work elsewhere. Again, when the burden of maintaining compatibility becomes too great, it will be obviously time to move to Java 6. On the other hand, how long will an API redesign take? Maybe the right approach is to start with Java 6, then whoever likes to can investigate how much work it would take to restore Java 5 compatibility. This could even be done with multiple mvn modules. Matt ... Christian Matt Cheers Matt On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote: On 5 December 2011 18:10, henrib hen...@apache.org wrote: sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... No, I don't consider that a valid reason on its own. Committing should be fun. If one does not want to support JDK 1.5 he goes away. Henri seems as he does not want and would like to put effort in a more modern environment. In addition, how many people can you attract with a JDK 1.5 version to contribute? For me this is valid reason. And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be
