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
