commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Wed, 24 Nov 2010 17:00:59 GMT

On Nov 24, 2010, at 8:18 AM, James Carman wrote:

> On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
> <scolebourne@joda.org> wrote:
>> 
>> For example, if a whole set of new features is added, it can be worth
>> using a new version number for marketing reasons (advertising the
>> major new features). This can result in a major version that is still
>> compatible.
>> 
>> It is also possible for a major version to remove just one or two long
>> deprecated methods. In this case, the pain of a package name change is
>> outweighed by the small likelihood of problems.
>> 
>> Finally, there are cases where the objects referred to are significant
>> value types that are widely used. In this case, changing the package
>> name is problematic as it causes other libraries that expose those
>> value types onwards to have problems.
>> 
>> As an example, Joda-Time may soon have a v2.0. Changing the package
>> name would be necessary if there was major incompatibility. However,
>> in the plan, Joda-Time 2.0 includes Java 5 generics support which is
>> 99% compatible, and the removal of just a handful of long deprecated
>> methods. Furthermore, since many, many other systems use Joda-Time in
>> their APIs, having two versions out there simply wouldn't work.
>> 
> 
> All of these examples would be situations where you'd make the case
> that this is an exception, which is allowed by the "rule".
> 

I disagree. The "rule" should be that a new package and artifactId is required when compatibility
is broken, not when a version change occurs. Exceptions should be based on that policy, not
on a version change occurs.

Ralph


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


Mime
View raw message