+1 Christian this is a nice idea - maybe RetentionPolicy.SOURCE annotations? (so we don't have to bring the dependency in each component for runtime...) Simo
http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 5, 2011 at 4:21 PM, Christian Grobmeier <grobme...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
