On 10/25/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Well, the number is dependent on the strategy we are trying to achieve: a) using '4' would indicate that every major version will have a new package name, but then you can't use a major version to just remove deprections (a compatible major version change) b) using '5' would indicate the technology reason for the version. The package would be commons-collections5-1.0. c) using '5' as the commons name - commons5-collections-1.0 I favour (b) as I view this as a fork of [collections] for a new technology. I believe the language changes in JDK5 are significant enough to warrant a fork.
The reason I don't think it's a fork is that I don't think we'll be saying "Use Old Collections in JDK 5.0" for any reason beyond backwards compat. This is the new version of Collections and the current one would be supported in the same way that the 2.x tree has been. Basically for something to be a fork we have to have a indefinite long term goal to keep both going - one does not replace the other. In this case it seems odd for us to maintain a non-generified version for reasons other than legacy. I can see it being intangible for a while and being a research branch rather than the mainline. The later d) of having collections2 is a bad idea - just look at the weirdness of "Axis2 1.0". With a), you suggested that we wouldn't have to change package names when a new major version only removed deprecations. Even in this case it seems that users are going to have pain; apart from a compiler warning a deprecation removal is the same as any other removal. So I think it's either a) or we let the user's deal with the pain as they have been up to now (said pain does create impetus for re-users to upgrade - though possibly they'll just inline the bits they use as with Spring). c) is going to be more painful to search and replace, and implies a common commons jar that we've never been in favour of before. b) implies a fork - though we did do net5 for net's new version didn't we? --- As a separate idea that someone suggested to me at work; how about a facade on top of collections that provides generified inputs/outputs. Could we extend the classes and wrap the static methods to get such a thing? Long term I'd prefer for the core collections to be generified with an old-style wrapper, but then we get into class compatibility issues (49 vs 48) and missing APIs when trying to target older jvms. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
