commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [all] Rebooting commons projects
Date Tue, 19 May 2009 01:10:46 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message