[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    Re: [VOTE] Release HttpComponents AsyncClient 4.0 based on RC2
From:       Oleg Kalnichevski <olegk () apache ! org>
Date:       2013-10-27 16:20:43
Message-ID: 1382890843.2283.3.camel () ubuntu
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]