.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
For additional commands, e
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
.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
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
Hi Gary!
On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com 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
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
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
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-PROCESS-Stability-versus-usability
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 aggregate
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.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
Sent from the Commons - Dev
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.
-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...@commons.apache.org
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.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus
-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
On 4 December 2011 10:41, 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.
+1, agree that we need to be clearer about what the intended external API is.
An annotation and a package naming
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 unsubscribe
a workaround for a lot
of these issues.
Phil
Best regards,
Henri
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
Sent from the Commons - Dev mailing list archive at Nabble.com
provide a workaround for a lot
of these issues.
Phil
Best regards,
Henri
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
Sent from the Commons - Dev mailing list archive at Nabble.com
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 something
. 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-tp4150322p4156330.html
Sent from the Commons - Dev mailing list archive at Nabble.com
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-versus-usability-tp4150322p4150322.html
Sent
21 matches
Mail list logo
