On Sun, May 17, 2009 at 3:16 PM, Stephen Colebourne <scolebou...@btopenworld.com> 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.
As always - I'm on the fence :) Or the grey area. Agreed in terms of massive rewrites under the same name. Tapestry4 + 5, Axis2 etc - it causes pain that takes a long time to heal and I'm not sure the innovation is worth having stuck with the brand. Of course then we have the mod_jk, mod_ajp, mod_jk2, whatever else bit where different products are solving the same problem and the users are confused again with a long tail before confusion ends. > 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. Agreed I think. When it's a project dumping flotsam, or moving to a new JDK, or refactoring where the code is. There the migration should largely be minor API changes as opposed to having to rethink the user code. Sure someone may have to recompile, or change the method name from isTrue to isVeryTrue; but it's the kind of backwards incompatibility that we need to have. Commons libraries that are not JDK 1.5 natural are now socially being end of lifed. > 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. Agreed - and I suspect the argument is that people will have different approaches to major :) Collections moving to 1.5 - not major in the Tapestry/Axis sense. I'm not sure if Lang will have to be the ugly 'Lang2 1.0' or 'Lang 3.0', or if the only place the 2 will show is in the Maven groupId, which as it's moving to org.apache.commons.lang means the whole issue might not be that big deal this time around :) Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
