On Tue, 2011-01-11 at 11:23 +0000, Moore, Jonathan wrote: > Well, the tradeoff here is that it breaks binary compatibility with the > previous 4.1 beta releases. > > I'm ok with removing it; we don't use it internally in the codebase anywhere > anymore, and I think it's unlikely someone built a new storage backend that > relied on it or tried to extend the cache module internals based on the beta > release. I'd certainly like to avoid shipping new GA code where some of the > new stuff is deprecated out of the starting gate. :) > > However, I'd like to hear Oleg's opinion on this -- he has pretty strong > feelings about binary compatibility (certainly well-placed when talking about > backwards compatibility for GA releases). > > Jon
Jon, Sebastian I personally think that the whole concept of binary compatibility for anything other than bugfix releases is simply flawed. I would love to be able to remove all deprecated code immediately. I would love to be able to upgrade HttpCore to Java 1.5 and make some other API changes here and there. The trouble is that binary compatibility is used by some as a criterion of a project's maturity and stability. For example, Google still ships a very outdated version of Httpclient with its Android platform supposedly because half a dozen variables were made final between the official API freeze and the 4.0 GA release. Basically it is up to us to decide whether or not we want to adhere to strict interpretation of the API / ABI compatibility rules. For instance, Lucene simply does not guarantee API compatibility between minor release. Period. No one (as far as I know) had a heart attack because of that. Having said all that I do think we ought not break the API compatibility because of a lone deprecated method. As long as we do not have a very strong case for breaking the API we should continue to maintain it. However, I can well imagine that we collectively decide that all code deprecated between 4.0-beta1 and 4.1 GA be removed in the 4.2 branch, run an open vote on it, and, if approved, stick to that decision. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
