--- On Mon, 5/18/09, Jörg Schaible <joerg.schai...@gmx.de> wrote:
> From: Jörg Schaible <joerg.schai...@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 <gudnabr...@yahoo.com>
> wrote:
> >> --- On Wed, 5/13/09, James Carman <ja...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
