commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [all] Rebooting commons projects
Date Mon, 18 May 2009 01:39:28 GMT
On Sun, May 17, 2009 at 8:04 PM, Henri Yandell <flamefew@gmail.com> wrote:
> On Sun, May 17, 2009 at 3:16 PM, Stephen Colebourne
> <scolebourne@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message