On 10/21/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Henri Yandell wrote:
> Why not just start a branch within Collections?
>
> I don't see why this is a new component, are we going to be advising
> people to use Collections 3.x on JDK 1.5+ for any reasons other than
> legacy or instability of our generified version?
>
> My view is to make a collections-generics branch in collections with a
> view to it being Collections 4.0.
Because commons isn't like other OSS projects. We can't go around
changing our APIs freely, even between major versions. Its a simple case
of us being at the bottom of the stack of jars. If we do change an API,
any API then jar hell ensues because higher OSS projects will clash on
their required versions of [collections].
Thus, it has to be a new package, and this is best thought of as a new
component.
I'm not convinced by that. What you're saying is that if we want to
have a major API change in a component, that we need to change the
package name so two pieces of code can sit side by side. If that's
true, then we should do it for all major versions (as major API change
is the defining factor of major version changing) and stay within the
same component.
Having a bit of deja vu - think we had this discussion 6 months ago :)
Basically - we need to start putting the major version in our package
names. I hate that, but I can see the need.
So this would be a branch of collections, with a package name change
to org.apache.commons.collections4.*.
Would be sweet to have a build system that could deal with moving
source from org/apache/commons/collections/ to the correct directory
and package name prior to compiing/source-packaging. Might be worth
playing with some Ant scripts for that.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
