commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: [all] Rebooting commons projects
Date Mon, 18 May 2009 13:40:25 GMT



--- On Mon, 5/18/09, Jörg Schaible <joerg.schaible@gmx.de> wrote:

> From: Jörg Schaible <joerg.schaible@gmx.de>
> Subject: Re: [all] Rebooting commons projects
> To: dev@commons.apache.org
> Date: Monday, May 18, 2009, 2:19 AM
> Matt Benson wrote at Sonntag, 17. Mai
> 2009 22:31:
> 
> > --- On Sun, 5/17/09, Matt Benson <gudnabrsam@yahoo.com>
> wrote:
> >> --- On Wed, 5/13/09, James Carman <james@carmanconsulting.com>
> >> wrote:
> 
> [snip]
> 
> >> > The point (at least mine) is that we don't
> *need* to
> >> create
> >> > a new
> >> > project here.  We have the ability (if
> we jump
> >> major
> >> > version numbers
> >> > and change package names) to be innovative
> with the
> >> > existing projects.
> >> >  We don't have to guarantee backward
> >> compatibility between
> >> > major
> >> > versions.
> >> > 
> >> 
> >> This has historically been the view taken in
> Commons, and
> >> I'm not seeing a consensus to change that view.
> > 
> > [SNIP]
> > 
> > Or, to put it another way, the consensus seems to be
> that the component +
> > the major version # makes a "project."
> 
> I think we more or less all agree that such a new component
> should play nice
> with an older version in the classpath. However, while I am
> all for
> evolving the current project with a new major release, we
> have to consider
> that it is not possible to have the same artifact twice in
> the same Maven
> project with a different version only. It does not matter
> if foo-1.x can be
> used at same time with foo-2.x, Maven does simply not
> support this
> scenario. Therefore we would have to change the artifact
> name anyway to
> something like foo2-2.x ...
> 

Which still resounds with my preceding statement, though I admittedly hadn'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 component name for the m2 artifact, and do likewise for our o.a.c.*-level
package.  Having done all this our users have complete freedom to upgrade what they want,
continue using other 3p libs that require [component]-previousVersion.n.n, etc.

Stephen, 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 enthusiastic
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 changes will NOT be a full redesign of a given component...

So what do you say to that?  ;D

-Matt

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


      

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


Mime
View raw message