commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...
Date Wed, 24 Nov 2010 16:07:29 GMT
On 24 November 2010 15:36, James Carman <james@carmanconsulting.com> 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
> [X] -1 - do not accept this as a rule

Components should be allowed to increment the major version even if
there is no binary incompatibility.

A package name change forces total binary incompatibilty.

> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message