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
