Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=fX7HPw13yswwgs9ASXg7ikdcdKS9kB22+1fmUDyTAR3YzlD6beYaputVPweIfCt5ldVWGnB+JKYLzDtimOo7T50rqJiImxrZCP243upBQT8CF0NgyU/rAM6FxCIny/KGR+E4KyXOWKpph0eCslkTmic3L3iNClH9If5oK1i1KO8=;
Message-ID: <240439.82407.qm@web55104.mail.re4.yahoo.com>
Date: Mon, 18 May 2009 06:40:25 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: Re: [all] Rebooting commons projects
To: Commons Developers List <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


=0A=0A--- On Mon, 5/18/09, J=F6rg Schaible <joerg.schaible@gmx.de> wrote:=
=0A=0A> From: J=F6rg Schaible <joerg.schaible@gmx.de>=0A> Subject: Re: [all=
] Rebooting commons projects=0A> To: dev@commons.apache.org=0A> Date: Monda=
y, May 18, 2009, 2:19 AM=0A> Matt Benson wrote at Sonntag, 17. Mai=0A> 2009=
 22:31:=0A> =0A> > --- On Sun, 5/17/09, Matt Benson <gudnabrsam@yahoo.com>=
=0A> wrote:=0A> >> --- On Wed, 5/13/09, James Carman <james@carmanconsultin=
g.com>=0A> >> wrote:=0A> =0A> [snip]=0A> =0A> >> > The point (at least mine=
) is that we don't=0A> *need* to=0A> >> create=0A> >> > a new=0A> >> > proj=
ect here.  We have the ability (if=0A> we jump=0A> >> major=0A> >> > versio=
n numbers=0A> >> > and change package names) to be innovative=0A> with the=
=0A> >> > existing projects.=0A> >> >  We don't have to guarantee backward=
=0A> >> compatibility between=0A> >> > major=0A> >> > versions.=0A> >> > =
=0A> >> =0A> >> This has historically been the view taken in=0A> Commons, a=
nd=0A> >> I'm not seeing a consensus to change that view.=0A> > =0A> > [SNI=
P]=0A> > =0A> > Or, to put it another way, the consensus seems to be=0A> th=
at the component +=0A> > the major version # makes a "project."=0A> =0A> I =
think we more or less all agree that such a new component=0A> should play n=
ice=0A> with an older version in the classpath. However, while I am=0A> all=
 for=0A> evolving the current project with a new major release, we=0A> have=
 to consider=0A> that it is not possible to have the same artifact twice in=
=0A> the same Maven=0A> project with a different version only. It does not =
matter=0A> if foo-1.x can be=0A> used at same time with foo-2.x, Maven does=
 simply not=0A> support this=0A> scenario. Therefore we would have to chang=
e the artifact=0A> name anyway to=0A> something like foo2-2.x ...=0A> =0A=
=0AWhich still resounds with my preceding statement, though I admittedly ha=
dn't thought it through that far.  So anytime the API changes in a breaking=
 way we need to jump major versions, append the new major version to the co=
mponent name for the m2 artifact, and do likewise for our o.a.c.*-level pac=
kage.  Having done all this our users have complete freedom to upgrade what=
 they want, continue using other 3p libs that require [component]-previousV=
ersion.n.n, etc.=0A=0AStephen, you've indicated your intent to forfeit your=
 -1 prerogative based on your having been drawn off to other things for the=
 past year or two; at the same time I'd prefer to feel all PMC members who =
remain even perfunctorily engaged are at least satisfied with if not enthus=
iastic about whatever approach is settled upon.  :)  I really feel, however=
, that the above mitigates your expressed concerns, particularly when taken=
 in consideration with the fact that probably half the time our breaking ch=
anges will NOT be a full redesign of a given component...=0A=0ASo what do y=
ou say to that?  ;D=0A=0A-Matt=0A=0A> - J=F6rg=0A> =0A> =0A> --------------=
-------------------------------------------------------=0A> To unsubscribe,=
 e-mail: dev-unsubscribe@commons.apache.org=0A> For additional commands, e-=
mail: dev-help@commons.apache.org=0A> =0A> =0A=0A=0A      

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org