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)
Date: Tue, 6 Dec 2011 02:47:24 -0800 (PST)
From: henrib <henrib@apache.org>
To: dev@commons.apache.org
Message-ID: <1323168444360-4164209.post@n4.nabble.com>
In-Reply-To: <jbjfot$r93$1@dough.gmane.org>
References: <1322865949872-4150322.post@n4.nabble.com>
 <jbjfot$r93$1@dough.gmane.org>
Subject: Re: [RELEASE PROCESS] Stability versus usability
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi J=C3=B6rg;
I've amended the idea based on feedback to *internal* package and @internal
annotation (for pragmatic reasons: a good rule is one which is easy to
follow and enforce).=20
The naming convention or the annotation would allow clear but also explicit
boundary; documentation is necessary but not sufficient IMHO. It should be
possible to determine automatically whether "public" code unintentionally
exposes or uses an @internal class by transitivity.
I agree that packaging should be the preferred way but sometimes, it may be
too hard/long/costly to refactor the project; "sprinkling" annotations woul=
d
not be ideal but would still allow control over the API stability.
Cheers,
Henrib

PS: We might need @experimental or @beta for APIs intended for public use
but not stable enough to make a hard cast-in-stone stable contract.


--
View this message in context: http://apache-commons.680414.n4.nabble.com/RE=
LEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

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