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] Release HttpComponents AsyncClient 4.0 based on RC2
Date Sun, 27 Oct 2013 16:20:43 GMT
On Sun, 2013-10-27 at 14:08 +0000, sebb wrote:
> On 27 October 2013 13:39, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Sat, 2013-10-26 at 12:31 +0100, sebb wrote:
> >> On 26 October 2013 12:02, Oleg Kalnichevski <olegk@apache.org> wrote:
> >> > On Sat, Oct 26, 2013 at 11:42:06AM +0100, sebb wrote:
> >> >> On 22 October 2013 19:32, Oleg Kalnichevski <olegk@apache.org>
wrote:
> >> >> > Please vote on releasing these packages as HttpComponents AsyncClient
> >> >> > 4.0. 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:
> >> >> > https://dist.apache.org/repos/dist/dev/httpcomponents/httpasyncclient-4.0-RC2
> >> >> > revision 3323
> >> >> >
> >> >> > Release notes:
> >> >> > https://dist.apache.org/repos/dist/dev/httpcomponents/httpasyncclient-4.0-RC2/RELEASE_NOTES-4.0.x.txt
> >> >> >
> >> >> > Maven artefacts:
> >> >> > https://repository.apache.org/content/repositories/orgapachehttpcomponents-020/org/apache/httpcomponents/
> >> >> >
> >> >> > SVN tag:
> >> >> > https://svn.apache.org/repos/asf/httpcomponents/httpasyncclient/tags/4.0-RC2
> >> >> > revision 1534621
> >> >> >
> >> >> > --------------------------------------------------------------------------
> >> >> > Vote: HttpComponents AsyncClient 4.0 release
> >> >> > [ ] +1 Release the packages as HttpComponents AsyncClient 4.0.
> >> >> > [X] -1 I am against releasing the packages (must include a reason).
> >> >>
> >> >> Clirr reports errors in both httpasyncclient and httpasyncclient-cache.
> >> >>
> >> >> I think these need to be investigated and addressed indivually.
> >> >> Either by fixing the incompatibility, or by establishing that a
> >> >> particular change is not likely to be a problem in practice and
> >> >> documenting it in the release notes.
> >> >>
> >> >> The previous release was a beta release, not alpha, so compatibility
> >> >> ought to be maintained.
> >> >>
> >> >
> >> > Sebastian,
> >> >
> >> > This release is expected by Apache CXF and Spring and a fairly substantial
number of individual users who are no less important. I do make my very best to accommodate
to your wishes and demands and in other circumstances would comply with them as many times
before. In this case though I will have to seek the required majority of votes to secure the
release.
> >>
> >> This is not my personal demand.
> >> I'm trying to make sure that we don't break 3rd party applications
> >> unnecessarily.
> >>
> >
> > By doing what exactly? By blocking the first GA release that tries to
> > establish a stable API baseline?
> 
> As I already wrote, Clirr errors need to be investigated and addressed.
> 
> Either by recoding to remove them, or by ensuring that the errors are
> clearly documented.
> 
> The latter should be easy enough to do, and with Gradle I assume
> re-rolling the release should also be easy.
> 
> > There is _nothing_ that mandates full
> > binary compatibility between BETA releases, especially for a x.0
> > product.
> 
> This ought to be documented going forward.
> 
> But regardless, it's important that the end-users are informed of such changes.
> 
> > I kept RC1 vote open for about a week fully anticipating some random
> > stuff from you like blank lines in license / notice files. There was
> > ample of time to make whatever adjustments to the release that you
> > deemed necessary.
> 
> I have not -1'ed a release purely on blank lines and you know that.
> Also I am not the only person concerned about the compatibility issue.
> 
> Unfortunately problems are sometimes not found the first time round.
> I agree it's a nuisance to re-roll the release with the updated docs,
> but it will help some end users and may prevent some error reports
> from beta users
> 

Extra work of re-rolling the release is not a problem, but delaying the
release by another week while people are waiting is. At least for me.

I will happily add a paragraph on binary compatibility to the release
announcement but I will not cut another RC. 

I'll tally the vote shortly.

Oleg  


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


Mime
View raw message