Hi Stephen and Henri, Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM:
> 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. It is also about branding. Collections is a well-known name in the community. Think of three years from now. If we declare collections 4.x needs JDK 1.5+ now, in 3 years nobody will rermember, that the older versions did support JDK 1.3. But the name for collections still persist. That's the political reason, not to change the name. > (Compare this with the JDK where they had to jump through ridiculous > hoops to make generics fully backwards-compatible, and created a > half-arsed mess in the process...) This is the real problem. We must use a different namespace for the Java package itself. A lot of stuff depends on c-c (http://www.mavenregistry.com/search/artifact/19973 + http://www.mavenregistry.com/search/depended_upon_artifacts, quite impressive) and even in 3 years there will be stuff available that still depends on those old versions. A new package name solves the problem of coexistence as long as the jar name contains the version (e.g. commons-collection-3.1 & commons-collection-4.2) but it creates new problems for e.g. Maven, that cannot handle two (binary distinct) versions at the same time. So there are three points to decide: - does a new package name imply a different Jakarta Commons project? - shall we give up existing brands (it means in the end the establishment of a new brand for all commons projects)? - if we keep the project name, do we have to accept the inevitable limits of popular tools such as Maven? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
