On 28 November 2011 13:51, henrib wrote:
> One might argue that JEXL does not have that many users so jar hell is very
> (very) unlikely - no Apache project depends on jexl2 afaik - and that
> forcing "up to date/snapshot" users to switch to a new package when they're
> already used to recompile a
One might argue that JEXL does not have that many users so jar hell is very
(very) unlikely - no Apache project depends on jexl2 afaik - and that
forcing "up to date/snapshot" users to switch to a new package when they're
already used to recompile against the latest JEXL version is adding burden
on
On 28 November 2011 12:03, James Carman wrote:
> I don't think that is either an apache thing or a rule. It's more of a
> commons best practice. It's one we strongly suggest for good reason,
> though.
Yes, because commons components are generally low-level libraries
which can be part of a depen
I don't think that is either an apache thing or a rule. It's more of a
commons best practice. It's one we strongly suggest for good reason,
though. Make sure the maven artifactId (and probably groupId too) changes
correspondingly. This will allow older versions to coexist with new ones.
On Nov
Gary and Sebb pointed out that, per apache release rules, incompatible binaries
require new package name (i.e. jexl3).
My bad, sorry.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e
