commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: [RELEASE PROCESS] Stability versus usability
Date Mon, 05 Dec 2011 15:21:19 GMT

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


On Sun, Dec 4, 2011 at 11:41 AM, henrib <> 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:
> Sent from the Commons - Dev mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message