Hi Jörg; 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). 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 would 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/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html Sent from the Commons - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
