On 24 April 2012 12:13, Oleg Kalnichevski <olegk@...> wrote:
> On Tue, 2012-04-24 at 02:48 +0100, sebb wrote:
>> On 23 April 2012 14:33, sebb <sebbaz@...> wrote:
>> > On 21 April 2012 12:21, Oleg Kalnichevski <olegk@...> 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)
>> [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.
> 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 . The changes
> have also been announced early enough (several releases in advance) .
> 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 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.
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
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.
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.
We can take the opportunity to fix the @deprecated markers (and the
HTTP constants ?).