p://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
F
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
ng with the
API contract and for release voting, it gets easier to control that we've
not unintentionally screwed it up.
Oh, and I do agree on the immutability / thread safety doc. :-)
Cheers,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCE
nded 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
>&g
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
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
> @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 us
formation 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-tp4150322p41565
ions.
>
> 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:
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
.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 com
/methods to find those @internal. One could even dream
of a -your favorite IDE here- plugin that warns you when using one of those.
If there is an easy / easier practical solution that could serve the same
purpose, I'm all for it!
--
View this message in context:
http://apache-commons.68041
in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156394.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commo
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.
tively exempt from version compatibility
> requirements. That could by itself provide a workaround for a lot
> of these issues.
>
> Phil
>> Best regards,
>> Henri
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.
preserve innovative contributions and
provides a clearer view of the stable contract. Seems like a win-win.
Best regards,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p415633
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
ackages, but which are not intended for use by external
applications and effectively exempt from version compatibility
requirements. That could by itself provide a workaround for a lot
of these issues.
Phil
> Best regards,
> Henri
>
> --
> View this message in context:
> http://apa
some
kind?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4154703.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubs
version but may change in
each minor with no warning
We might also use a clear 'internal' sub-package name as a frontier
delimiter on the same rule.
Thoughts ?
Best regards,
Henri
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-vers
21 matches
Mail list logo
