Matt Benson wrote:
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...
As a minimum, major changes require a package name change, and as has
been pointed out a maven id change.
So:
(1) minor incompatible changes (remove long deprecated methods or fix
details at the edges). These are compatible for 99% of users and can be
a major version (or perhaps minor) with no package or maven name change.
(2) major incompatible changes (moving classes between packages,
changing how the code is used, anything that causes the user to need to
reread docs, inability to use new version as a dependency for something
compiled using old version). These can be thought of as a major version
change with associated package name change and maven name change.
(3) major reboot (same problem space, but lots of rewrite), I'd still
strongly prefer to see these in the sandbox (eg cli2). Socially, they
are often a different set of committers with a subtly different set of
design ideas (all good things). Although the sandbox approach is
preferable, my minimum requirement however is a major version change
with package name change and maven name change.
Hopefully, each set of changes can be classified into one of those three
groups. However, IMO [collections] and [cli] are both cases that would
have been better off taking the sandbox route.
Personally I'm surprised that the sandbox route isn't more popular as it
allows proper innovation with no limits (ie. no one like me looking over
the shoulder...). Maybe, its a fear of difficulty in getting it
promoted. Maybe its a desire to retain the brand name of the original.
Maybe a separate thread should identify the fears.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
