On Sun, May 17, 2009 at 8:04 PM, Henri Yandell <flame...@gmail.com> wrote: > 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.
One key difference between the tapestry case and what we're discussing is that there was absolutely no migration path in the tapestry case. Switching over to using classes in commons functor wouldn't be that difficult (find/replace?) I would imagine. Of course, I'm addressing a specific case (collections/functor), but I do tend to agree that we don't want to go overboard with completely rewriting something. In fact, I was one of the loudest protesters about the T5 stuff (which is also why I'm using Wicket now). I see where you're coming from, Stephen. However, if we explicitly disclose the expectations up front, perhaps there won't be as much backlash? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
