commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From henrib <>
Subject [RELEASE PROCESS] Stability versus usability
Date Fri, 02 Dec 2011 22:45:49 GMT

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 lost of components, the stability users.
Others are looking for best-of-breed/narrow scope/malleable libraries a with
a guaranteed quality, the usability users.
Thus the importance of clearly stating in our libraries what is 'stable' and
what is 'usable'.
The expressiveness in the language itself is not enough to properly describe
the contract made regarding each party; i.e. sometimes things have to be
public but should not be considered part of the API that follow the
major,minor - deprecation.
I believe we can come up with a set of agreeable rules to please both
"camps" be through some naming convention in packages and annotations.

As an kickstart proposal, may be something as simple as 2 annotations
actually could be enough: @stable, @usable.
@stable meaning the contract this API represents will not change without
being first @deprecated
@usable meaning this API is valid for this major 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,

View this message in context:
Sent from the Commons - Dev mailing list archive at

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

View raw message