On Sun, May 17, 2009 at 11:29 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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.
HttpClient is another example that is complained about by users :) The only saving grace of v4 is that it is now named HttpComponents Core (fitting Stephen's suggestion of a new name). Of course that means users are also confused due to change in brand and complaining about that. Should they use HttpComponents? HttpClient? 6 of 1 etc. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
