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. >> But I've tried HttpCore 4.2 with JMeter 2.6, and a brief test does not >> show any problems, which is encouraging. >> >> Also, most of the changes were already introduced in 4.2-alpha2 and >> 4.2-beta1, so hopefully we would have found out about any major >> problems from users of those releases. >> >> However I do think we need to flag up these changes, so I would be in >> favour of a respin to update the release notes. > > Sure. Please let me know what you would like to be included in the > release notes (or just update the notes as you deem appropriate) OK. >> We can take the opportunity to fix the @deprecated markers (and the >> HTTP constants ?). >> > > I'll fix the constants but updating all the @deprecated markers that we > have accumulated since 4.0 would be a lot of work. Is this a deal > breaker for you or not? Not a deal breaker; but I'm working through the updates now and it would be good to get them in the release if poss. > Oleg > >> > Oleg >> > >> > [1] http://markmail.org/message/mcvcy4ylxwhalv6h >> > [2] http://markmail.org/message/2u3qk2fzig6umtaf >> > >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> 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] >> >> >> > >> > >> > >> > --------------------------------------------------------------------- >> > 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] >> > > > > --------------------------------------------------------------------- > 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]
