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
Hi Henri,
henrib wrote:
>
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
>
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggre
About the *internal* and @internal (package & annotation);
Of course if we could come up with a "binding" convention on the source
layout and package name for all projects, it would be really nice (i.e. the
*internal* package convention).
(Oh, a common pom where only the source/test/site would be
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I
On 5 December 2011 15:42, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
If your component is pa
Hi Gary!
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I u
Personally, I do not like annotations to describe the stability of an API.
If it's public I can use it. The next release is binary and/or source
compatible, just document how to migrate. No one is forcing me to upgrade.
If I upgrade, I am using a new pile of code and I must deal with that.
Using
+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
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 shou
On 4 December 2011 10:41, henrib wrote:
> Keeping track as it evolves based on feedback;
>
> Goal is to allow easy definition, usage and check of stable APIs.
+1, agree that we need to be clearer about what the intended external API is.
> An annotation and a package naming convention allow the p
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 declar
ralph.goers @dslextreme.com wrote
>
> The part I'm struggling with is that if these are annotations vs just
> javadoc tags then I would expect some kind of either compile time or
> runtime behavior (or both). It seems that you are proposing javadoc tags
> instead? If not what behavior would the
Stefan Bodewig wrote
>
> Would you have known at the point when JEXL 2.0.1 has been released
> which APIs you'd mark up as @stable or @usable?
>
Yes for most and in doubt, I could have marked them @usable (or @internal
which may be a better term).
--
View this message in context:
http://apach
On 2011-12-04, henrib wrote:
> When trying to release JEXL 2.1, the API was disrupted and the clirr report
> was outputing lots of clutter.
> As the dev, it became very hard to understand whether the change was
> actually breaking the intended stable API or just some internal methods or
> class.
The part I'm struggling with is that if these are annotations vs just javadoc
tags then I would expect some kind of either compile time or runtime behavior
(or both). It seems that you are proposing javadoc tags instead? If not what
behavior would the annotations cause?
Ralph
On Dec 3, 2011,
Phil Steitz wrote
>
> In practical terms, it might be hard to decide what to put where.
> Can you provide some examples based on recent RCs?
>
When trying to release JEXL 2.1, the API was disrupted and the clirr report
was outputing lots of clutter.
As the dev, it became very hard to understand
On 2011-12-02, henrib wrote:
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
I'm glad you say that right at the beginning as the "versus" in the
subject line seems to imply somethi
eers,
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
De: Phil Steitz
Para: Commons Developers List
Enviadas: Sábado, 3 de Dezembro de 2011 23:22
Assunto: Re: [RELEASE PROCESS] Stability versus usability
On 12/2/11 3:45 PM, henrib wrote:
> It seems
On 12/2/11 3:45 PM, henrib wrote:
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
>
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to a
Since it may need clarification;
The idea would be to allow a clirr report to give accurate analysis of
whether the external / stable API has been modified.
Methods or classes annotated as @stable, could not change from one version
to another before they are @deprecated.
Methods or classes annotat
20 matches
Mail list logo
