On Tue, 2011-01-11 at 13:31 +0000, sebb wrote: > On 11 January 2011 12:36, Oleg Kalnichevski <[email protected]> wrote: > > 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. > > I find that hard to believe. > > It's more likely that they have not allocated resources to do the > necessary acceptance testing. >
I believe this is what Bob Lee mentioned as a reason why Google had not upgraded to HC 4.0 GA when it was out, if my memory does not fail me. It is all in the mail archives. We can dig it out. I think it no longer matters, though. ... > There are also degrees of incompatibility, depending on how likely it > is that the method is used. > > In this particular case, the method has never been part of a GA > release, which I think is borderline. > > The release notes say: > > =========================== > Release 4.1 BETA1 > ------------------- > HttpClient 4.1 BETA1 finalizes the 4.1 API and brings a number of > major improvements to the HTTP > caching module. > ... > Release 4.1 ALPHA2 > ------------------- > ... > Compatibility notes > ------------------- > (1) Please note the HTTP caching module is still considered experimental and > its API may change significantly in the future releases. > =========================== > > The RN don't say that the caching module is no longer considered experimental. > I think it's arguable that the caching API may still change. > That would really be a stretch in my opinion. > > 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. > > If we are not agreed on removing the method now, we should run that > vote now, so we can update the Javadoc accordingly. > The trouble is that ideally we should start with HttpCore first. We could release HttpCore 4.1.1 as 4.2 and clearly state in the release notes that the next feature release (4.3) will have code deprecated between 4.0-beta1 and 4.1 removed. Honestly, I just do not think this one bloody method is worth delaying the 4.1 GA release. Let us cut 4.1 GA soon and then decide on the development road map for 4.2, 4.3 or 5.0 Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
