Why can't we
just keep the Commons Collections name (and packages, etc.), but
just use
the version numbers to keep it straight? Tomcat 5.5.x requires JDK5.
Couldn't we just say that Commons Collections 4.x (and beyond)
requires
JDK5? That way, for those folks who want to upgrade, it's not
very tough.
For the most part, the classes/methods will have the same names.
On 10/23/06, Jörg Schaible <[EMAIL PROTECTED]>
wrote:
>
> 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.xneeds 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
>
