On 24 April 2012 18:28, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2012-04-24 at 18:07 +0100, sebb wrote: >> On 24 April 2012 17:18, Oleg Kalnichevski <[email protected]> wrote: >> > On Tue, 2012-04-24 at 16:59 +0100, sebb wrote: >> >> On 24 April 2012 16:03, Oleg Kalnichevski <[email protected]> wrote: >> >> > On Tue, 2012-04-24 at 15:18 +0100, sebb wrote: >> >> >> On 24 April 2012 12:13, Oleg Kalnichevski <[email protected]> wrote: >> >> >> > On Tue, 2012-04-24 at 02:48 +0100, sebb wrote: >> >> >> >> On 23 April 2012 14:33, sebb <[email protected]> wrote: >> >> >> >> > On 21 April 2012 12:21, Oleg Kalnichevski <[email protected]> >> >> >> >> > wrote: >> >> >> >> >> Please vote on releasing these packages as HttpComponents Core >> >> >> >> >> 4.2. The >> >> >> >> >> vote is open for the at least 72 hours, and only votes from >> >> >> >> >> HttpComponents PMC members are binding. The vote passes if at >> >> >> >> >> least >> >> >> >> >> three binding +1 votes are cast and there are more +1 than -1 >> >> >> >> >> votes. >> >> >> >> >> >> >> >> >> >> Packages: >> >> >> >> >> http://people.apache.org/~olegk/httpcore-4.2-RC1/ >> >> >> >> >> >> >> >> >> >> Release notes: >> >> >> >> >> http://people.apache.org/~olegk/httpcore-4.2-RC1/RELEASE_NOTES.txt >> >> >> >> >> >> >> >> >> >> Maven artefacts: >> >> >> >> >> https://repository.apache.org/content/repositories/orgapachehttpcomponents-078/org/apache/httpcomponents/ >> >> >> >> >> >> >> >> >> >> SVN tag: >> >> >> >> >> https://svn.apache.org/repos/asf/httpcomponents/httpcore/tags/4.2-RC1/ >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------------- >> >> >> >> >> Vote: HttpComponents Core 4.2 release >> >> >> >> >> [ ] +1 Release the packages as HttpComponents Core 4.2. >> >> >> >> >> >> >> >> Sorry, I'm changing my vote: >> >> >> >> >> >> >> >> >> [X] -1 I am against releasing the packages (must include a >> >> >> >> >> reason). >> >> >> >> >> >> >> >> I've just noticed that Clirr reports several compatibility issues >> >> >> >> against 4.1. >> >> >> >> >> >> >> >> I've not investigated in any detail, but it looks as though at least >> >> >> >> some of these are binary compatibility issues, and they appear to be >> >> >> >> in public APIs. >> >> >> >> >> >> >> >> It may be that these are not actually a problem, but I think they >> >> >> >> need >> >> >> >> to be investigated further. >> >> >> >> If the errors are harmless - or perhaps only affect source builds - >> >> >> >> it >> >> >> >> would be helpful to update the site (and ideally release notes) >> >> >> >> accordingly. >> >> >> >> >> >> >> >> [No need to cancel the vote just yet, in case I'm wrong.] >> >> >> >> >> >> >> >> BTW, we recently added test jars to the Commons Maven output. >> >> >> >> This should make it easier to run old tests against new releases. >> >> >> >> >> >> >> > >> >> >> > Sebastian >> >> >> > >> >> >> > The reported differences in public APIs reported by Clirr are due to >> >> >> > two >> >> >> > things (1) upgrade from Java 1.3 to Java 1.5 (2) removal of code >> >> >> > deprecated between 4.0-beta1 and 4.0 (that is, before 4.0 GA, more >> >> >> > than >> >> >> > two years ago) >> >> >> > >> >> >> > We had a discussion about pros and cons of upgrading to Java 1.5 and >> >> >> > if >> >> >> > I remember it correctly you were in favor of that idea [1]. The >> >> >> > changes >> >> >> > have also been announced early enough (several releases in advance) >> >> >> > [2]. >> >> >> > They do make 4.1 and 4.2 not fully binary compatible but I seriously >> >> >> > doubt there will be a single user affected by incompatibility. >> >> >> > >> >> >> > I hope you will change your mind. >> >> >> >> >> >> I've been looking further at the changes. >> >> >> The changes to NIO are all removals of deprecated methods, so not a >> >> >> problem (or at least, not our problem). >> >> >> >> >> >> The removed methods in HttpCore are also deprecated methods, so not a >> >> >> problem. >> >> >> >> >> > >> >> > Not only were they deprecated, they are deprecated two release cycles >> >> > back (before 4.0 official release). >> >> > >> >> >> Not sure why the value definitions of HTTP.DEFAULT_CONTENT_CHARSET and >> >> >> DEFAULT_PROTOCOL_CHARSET were changed. >> >> >> Given that they are now deprecated, I would have thought the values >> >> >> could have been left untouched. >> >> > >> >> > I think the case changed (by mistake). I'll fix it right away. >> >> > >> >> >> However AFAICT that does not affect compatibility. >> >> >> >> >> >> [BTW, in future we ought to document in which release items are >> >> >> deprecated] >> >> >> >> >> >> That just leaves the changed method signatures, which are due to >> >> >> adding generics to Iterator in o.a.h.message.Basic*Iterator and to >> >> >> AbstractMessageParser. >> >> >> In the case of the MessageParser subclasses, these were also changed >> >> >> to use more specific subclasses: >> >> >> HttpRequest and HttpResponse instead of their common super-interface >> >> >> HttpMessage >> >> >> >> >> >> It's not obvious to me if these methods are likely to be called by 3rd >> >> >> party code or whether they are only likely to be used internally. >> >> >> >> >> > >> >> > You see, in any sane use case scenarios, especially as far as iterators >> >> > are concerned, the type returned from those methods would always be cast >> >> > to the expected subtype. In almost all cases regardless of how those >> >> > methods are being used the changes will have no effect at the runtime >> >> > behavior. >> >> >> >> The problem is that the return type of a method is part of the signature. >> >> Java won't find the method at runtime if the signature changes between >> >> compilation and run-time. >> >> >> >> This generally does not affect source compatibility, but it does >> >> affect binary compat. >> >> >> >> We had this exact problem in Commons IO >> >> We wanted to change a method return from void to something else; >> >> however testing against pre-existing binaries showed that this broke >> >> binary compat. >> >> >> > >> > All right. I'll revert those changes. >> >> We are already making the assumption breaking the API is OK for >> long-deprecated methods, i.e. that user applications have migrated >> away from the deprecated methods. >> >> So if the methods in question are not likely to be used by 3rd party >> applications - are they effectively internal ? - we could consider >> releasing with such breaks in compat, provided that such changes are >> clearly documented. >> > > It is almost as easy just to deprecate the affected classes.
Which classes need to be deprecated? > What is done is done. Not sure I follow what you mean here. >> > I always thought the return type did not matter for binary method calls. >> > Obviously I was wrong. >> >> I originally thought the same. It was one of the long-time Commons >> devs who pointed out the problem. >> >> It's particularly strange that changing void to non-void matters, but it >> does. >> [Perhaps it was easier than making an exception for that particular case] >> > > I am not sure I understand the point of including the return type in the > method signature since there will always be ambiguity in case there is > no assignment of the method return to a variable. Not possible, see below. > int i = obj.dostuff(); // returns int > double d = obj.dostuff(); // returns double That's not possible; obj.dostuff() can only have a single return type (or void). Compiler complains about a "duplicate method" otherwise. > obj.dostuff(); // trouble > > That begs the question: what is the point of making things more complex > than necessary. I don't think they did make things more complex. > Anyway, as soon as you are happy with the content of the release notes, > I'll cut another RC and call a vote. I've made some fixes to the parent pom, because unfortunately the buildNumber plugin with javasvn implementation does not work with SVN 1.7+ clients. I assume you have not yet upgraded, because the "Implementation-Build" headers are OK in the Manifests, so that can be fixed later. > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
