Stephen Colebourne wrote: > > 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]. Henri wrote: > 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
Actually it was over [net], and recently. And yes, its not nice, but a different package name is all that we get given by Java at present. However, there are cases where a major version change can be done without breaking backwards compatability - typically, where the only change is to remove deprecations ([lang] 3?). We could just say that its the responsibility of everyone using commons to repackage our code into their package structure, but IMHO thats just not practical, and quite wasteful. > Basically - we need to start putting the major version in our package > names. I hate that, but I can see the need. Yep, it sucks. Yep, its essential. > So this would be a branch of collections, with a package name > change to org.apache.commons.collections4.*. 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. > 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. Not sure how that helps. The new JDK5 code will probably be a proper fork, with some significant method name/class changes. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
