hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] HttpComponents Core 4.2 release based on RC1
Date Tue, 24 Apr 2012 15:59:45 GMT
On 24 April 2012 16:03, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Tue, 2012-04-24 at 15:18 +0100, sebb wrote:
>> On 24 April 2012 12:13, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Tue, 2012-04-24 at 02:48 +0100, sebb wrote:
>> >> On 23 April 2012 14:33, sebb <sebbaz@gmail.com> wrote:
>> >> > On 21 April 2012 12:21, Oleg Kalnichevski <olegk@apache.org>
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: dev-unsubscribe@hc.apache.org
>> >> >> For additional commands, e-mail: dev-help@hc.apache.org
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> >> For additional commands, e-mail: dev-help@hc.apache.org
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > For additional commands, e-mail: dev-help@hc.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message