hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [VOTE] HttpComponents Core 4.2 release based on RC1
Date Tue, 24 Apr 2012 15:03:28 GMT
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.

> 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)

> 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?

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


Mime
View raw message