From dev-return-114293-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Mon May 18 00:04:51 2009
Return-Path:
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: (qmail 19440 invoked from network); 18 May 2009 00:04:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 18 May 2009 00:04:51 -0000
Received: (qmail 12056 invoked by uid 500); 18 May 2009 00:04:50 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 11927 invoked by uid 500); 18 May 2009 00:04:50 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Commons Developers List"
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 11917 invoked by uid 99); 18 May 2009 00:04:50 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 May 2009 00:04:50 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of flamefew@gmail.com designates 209.85.218.161 as permitted sender)
Received: from [209.85.218.161] (HELO mail-bw0-f161.google.com) (209.85.218.161)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 May 2009 00:04:40 +0000
Received: by bwz5 with SMTP id 5so3086330bwz.42
for ; Sun, 17 May 2009 17:04:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type
:content-transfer-encoding;
bh=AqsjkAqNe80C6cDvXtOIyj3e6lsnUUROz7TyXfoZgh8=;
b=u6a8XAw7jjoOrksV0S57uxIfvTnrRrQalGWi61WmV5VkET8v6iTfnRVEeox1Rb7Vcy
bqv4TES/+NSFdUtLu57+pl49x80QgXdX0Vfrx6EP3WdOqoY2ASrA/rwV6oyLaakcTbh3
7adQPN7w/7V/Kbz4hlDzNE0wq8ljz7sHjlilE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
b=C7pa8TQZfrErN2L7ghEu/Wd7bCYn0sw1/9PwnGKcBaYVNBtYIlFy+derKsM2JY8FIH
ym640HmX+lrAjsp5+8oJ1poWMUuL+buk2T0YLv7ZoiJWZUOVB2tn8xiXFJXnq93v5F4x
gWb/chmARJfIuNCTTVl/Q0+jgHaA3VMOGXOMc=
MIME-Version: 1.0
Received: by 10.223.126.1 with SMTP id a1mr3860804fas.78.1242605060310; Sun,
17 May 2009 17:04:20 -0700 (PDT)
In-Reply-To: <4A108CD9.8040602@btopenworld.com>
References: <489065.91062.qm@web55105.mail.re4.yahoo.com>
<4A108CD9.8040602@btopenworld.com>
Date: Sun, 17 May 2009 17:04:20 -0700
Message-ID: <31cc37360905171704p22279e75t8272927dcedaf59f@mail.gmail.com>
Subject: Re: [all] Rebooting commons projects
From: Henri Yandell
To: Commons Developers List
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
On Sun, 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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org