On 11/1/06, Stephen Colebourne <[EMAIL PROTECTED]> 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
(http://apr.apache.org/versioning.html), 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.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
