Henri, I would love to see this as a Commons recommendation on the Wiki. As Stefan mentioned, in Compress we have @experimental annons (I actually added them). I like the idea to make up a public, rarely to break interface api and some not so public sometimes to break implementation. Maybe we should even consider to create an interface jar and an implementation jar of different versions. On the other hand this makes things complex - but anyway....
Cheers Christian On Sun, Dec 4, 2011 at 11:41 AM, henrib <hen...@apache.org> wrote: > Keeping track as it evolves based on feedback; > > Goal is to allow easy definition, usage and check of stable APIs. > An annotation and a package naming convention allow the project developer to > clearly state when a class/method/field is not part of the stable contract > despite a public/protected declaration but only of the internal part of the > project. > > @internal annotated class/method or *internal* package mean "use this at > your own maintenance cost"; those are not part of the "public" API. They can > be used and extended but are subject to change between versions without > @deprecated annotations. > > Those annotations and conventions should allow feeding a clirr report with > the proper information to allow detection of unintended API breakage and may > even allow creating IDE plugins to warn about usage. > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
