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.
So, to be crystal clear. In my opinion, even changing the major version of a well known project doesn't entitle it to go and have major changes.
And given that restriction, it should be clear that only a new project tackling the same problem space can provide the desired innovation.
Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
