commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [PROPOSAL] Major versions require package name change
Date Sun, 05 Nov 2006 03:00:09 GMT
On 11/1/06, Stephen Colebourne <> wrote:
> An attempt at a summary on this topic.
> The majority view on the thread was that a major version should not be
> mandated to mean a package rename. Instead, the view most widely
> expressed was that this should be a component decision.
> A second angle to emerge is that a 'large non-compatible change', as per
> [collections] for generics, may in fact be a change larger than our
> current major version number expresses. Going forward, this may argue
> for a different component name, if package renaming does not have
> widespread support.
> I'm not planning on bringing this to a vote, as it would be defeated as is.
> Stephen

Sorry to be late to the party on this.  I have been a little busy, but
honestly mostly just unable to make up my mind on where I come down on
the core issue. I agree that this is a very important issue and I
thank you for raising it.  While we have a long tradition of allowing
individual components to make their own decisions, I think that when
it comes to version numbering and compatibility rules, we really
should have a common strategy.  I like the rules that apr uses
(, which (translated to Java)
are close to conventional practice in commons.

I agree with Niall that we should use deprecation and other means to
progress things while preserving compatibility, but understand that
there are situations where really significant incompatible change is
necessary.  In that case, I support the recommendation in the
proposal, and I would be +1 to requiring a package name change to
signal this.  One thing that we might consider, though, is allowing
the package name change to be only at the lowest level - i.e., the
subpackage containing the incompatible change, e.g.
org.apache.commons.math.linear2 as opposed to o.a.c.math2.  I would
still want to see the component version number moved a major increment
in this case.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message