Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of jodastephen@gmail.com
 designates 209.85.216.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=rP3KpMaoPqcNbCluIb9pwjH862SbRLMj3SYSkTPVfBUJ+gHl4zVuor6bFVJNzlv8wi
         bGvrmdV+uIzC5lsT8ofiSmmh3+Z3iP+j0M23d2lSxV7eYCvdQ1fYVO+46OgSGndE9XVE
         iIiwCMevB/+uMKoCJjree1xGrAIBgeq6CTbaw=
MIME-Version: 1.0
Sender: jodastephen@gmail.com
In-Reply-To: <AANLkTikvAPoAGUN5r+jzWthRBqddo_j3Y4Z2nLJ0g9e8@mail.gmail.com>
References: <AANLkTikvAPoAGUN5r+jzWthRBqddo_j3Y4Z2nLJ0g9e8@mail.gmail.com>
Date: Wed, 24 Nov 2010 16:11:37 +0000
Message-ID: <AANLkTimcwnSgCt=+QqUsCc_kcQ92KTVzg9PrQg8L_2-r@mail.gmail.com>
Subject: Re: [VOTE] Accept the package name/artifactId guideline as a
 "rule"...
From: Stephen Colebourne <scolebourne@joda.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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
incompatibility.

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.

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.
Stephen


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. =A0What 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. =A0This is to avoid re-hashing this argument all the
> time. =A0If 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. =A0We 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. =A0I 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