Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: jcarman@carmanconsulting.com
From: James Carman <james@carmanconsulting.com>
Date: Wed, 24 Nov 2010 10:36:01 -0500
Message-ID: <AANLkTikvAPoAGUN5r+jzWthRBqddo_j3Y4Z2nLJ0g9e8@mail.gmail.com>
Subject: [VOTE] Accept the package name/artifactId guideline as a "rule"...
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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