On May 17, 2009, at 3:16 PM, Stephen Colebourne wrote:
Matt Benson wrote:
Or, to put it another way, the consensus seems to be
> that the component + the major version # makes a "project."
As I've said before, I won't try and stop this, I no longer have the
moral rights here. I do believe that this approach is profoundly
wrong however.
Consider an analagous case - Tapestry. Each major version of
Tapestry is known, with derision, as being extremely different to
the previous. This is to the extent that I, and I'm pretty sure
many, many others wouldn't touch Tapestry with a barge pole now
simply because we can't rely on it not being reinvented all the time.
A project name does imply something important about compatibility
even across major versions in my book.
For example, if I do release Joda-Time it will simply be a version
with the deprecated methods removed, and maybe a few edge cases
tweaked. Its the classic commons type library (even though its not
in commons). Imagine the chaos and confusion if I were to declare
the 'rebooted' jsr-310 as Joda-Time 2. Unthinkable. Yet, that is
exactly what is being proposed here.
Why would that be unthinkable? OTOH, if it becomes part of the JDK I
guess there is no point for a Joda Time 2.
The only time it is unthinkable is if the API changes so that old
applications can't use it without code changes AND the package names
stay the same. It serves no useful purpose, other than to confuse
everyone, to have commons-lang in proper and commons-lang-ng in the
sandbox. OTOH, having a package name like org.apache.commons.lang2
makes it quite clear it isn't compatible with the current release.
I think a great example is httpclient. It used to be part of commons.
Then it moved off to its own high level project. But if you go to
hc.apache.org you will find a version that is very different than what
most people are still using - version 3 (that might be because the
main web site has been for version 4 for quite a while but the formal
release only happened in February). Trying to actually find version 3
is a bit of an adventure as it is buried away under oac..But the
bottom line is, Version 4 is not API compatible with Version 3. The
same thing is true of Apache Maven 1 vs Maven 2.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
