On 10/25/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 10/25/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
<snip/>
>
> Having said that, its not me thats going to be doing the work, but it
> does seem valuable to discuss port vs. refactor rather than refactor
> being a defacto decission and just having an argument on package
> names.
>
<snap/>
:-)
Its not going to be me either, which is why I have (more or less)
retired from the conversation. You're right that this isn't about
package names, but really whether the intent is to produce a backwards
compatible generified collections:
There are two conversations overlapping each other :)
One is collections specific. What to actually do for the next major
version of collections/separate version of collections-generics.
The other is commons specific. When we make non-backwards compatible
API changes outside of the 0.x->1.0 dev cycle, do we let the user deal
with the random pain of transitive dependencies mismatching at runtime
after recompiling, or do we force them to deal with the non-random
pain of having to change their package names before recompiling.
This only really applies to recompiling - anyone who drops a major
version change in at runtime doesn't deserve any kind of support.
If you're pulling in a major version change, then it's also definitely
your responsibility to check your transitive dependencies. I don't
think we should be renaming packages to make that easier for people.
The only bit that makes the package rename tempting is that in many
cases the transitive is going to be more than just your development
group and commons, there will be other open source (well any external)
projects in between. So people will be held up from using those other
projects until they move.
I've mulled it for a bit, and I don't think that it's worth it for us
to try and change package names to make it easier for people not to be
held up by other entities. If we do that then there will be less
pressure for those projects to upgrade, and we'll just be causing lots
of pain for the many to save pain for a much smaller group. Admittedly
the many get their pain at compile time while the smaller group
wouldn't have found their pain until runtime if they don't have good
build practices.
Tomcat's not a good example btw - people rarely depend on Tomcat jars,
they don't put the major version in the package name (or any kind of
number) and there was lots of confusion when Tomcat 5 and 5.5 were
out.
So I'm -1 to the package stuff - just not convinced by the argument so
far. I do hope that we can get the generics stuff moving without the
package name bit being an issue until we release.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
