commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@scalaris.com>
Subject Re: Release JEXL 3.0 based on RC1
Date Tue, 29 Nov 2011 18:05:28 GMT
Hi Henri,

henrib wrote:

> I dont understand what is expected anymore...
> 
> There are some new features and fixes that break the API at the binary and
> source level; I'm merely applying the best practice recommendations - and
> previous 2.1 rejection basis.
> 
> This version has been 18 months in the making, fixes quite a few bugs and
> adds what could be considered major functionalities; making it a new major
> version does not seem stupid.
> Besides, the very scarce JEXL's community is expecting these changes and
> no other Apache component really uses JEXL 2. Besides, anyone using a
> scripting engine in a binary safe way will (should) use it through
> JSR-223...
> 
> What is the danger here, besides scaring off anyone trying to use JEXL ?
> Even if the next version is again a major one after 18 months (on
> average), would it be so bad ? I'm really puzzled and can't understand the
> motivation to reject (besides the artifactId).
> And if you feel disappointed, how would you feel if your work and time was
> only considered low quality or a waste by people who aren't actually using
> it? After all, may be OGNL is the way to go and JEXL moved to the attic...
> 
> Sorry for the rant and thanks for another lesson in humility.

As you said, this release was in the making for 18 months - so why do you 
try to rush it now in this way? Yes, the policy is, that we rename package 
and artifactId if we release a binary incompatible version (API-wise). 
However, if there is a possibility to make a API-wise binary compatible 
drop-in release, this has always to be preferred, since then no-one has to 
change package names in his own sources to use the new version.

And exactly that point is not yet cleared! Sebb tried to help by resolving 
the incompatible changes to make a preferred 2.1 release possible, but this 
research was not finished. If we break with every release the API of a 
component, it is also not a very good sign to our users also. And if it 
means to have some deprecated methods and classes - so what?

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message