commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Wed, 24 Nov 2010 16:11:37 GMT
While I hardly count as having a vote now, I do have an opinion ;-)

I think that the formulation below is too strong. I'd argue that
changing the package name is required when there is significant
incompatibility, but a major version change might not cause such

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

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.

By counter example, having two versions of a standalone utility like
StringUtils makes no difference, and having a package name change
might make sense in these cases.

As such, were I to be voting, I would vote -1.
Although I do understand the sentiment, more subtlty is required here
- package name changes are sometimes necessary, but must be treated
with care.

On 24 November 2010 15:36, James Carman <> wrote:
> We've had this package name/artifactId change discussion numerous
> times and I think it's time we put this thing to a vote.  What I
> propose is that we say that this is a rule and in order to "break"
> that rule, you have to provide strong evidence that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
> A major version change requires that you change the package name (the
> part that comes after org.apache.commons) and the Maven artifactId to
> the component's name with the major version appended to the end.
> [ ] +1 - accept this as a rule
> [ ] -1 - do not accept this as a rule
> Note that we already have a "rule" that says if you're going to break
> binary compatibility, you have to change the major version number, so
> this rule picks up where that one leaves off I guess.
> p.s.  We might also want to propose a rule that says any new releases
> of a commons component have to be done in the org.apache.commons
> groupId, but that's another issue.
> p.p.s. If anyone cares to restate this rule, please feel free to do
> so.  I may not have addressed certain "gotchas", but the general idea
> is presented.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message