On 26 October 2013 12:02, Oleg Kalnichevski <[email protected]> wrote: > On Sat, Oct 26, 2013 at 11:42:06AM +0100, sebb wrote: >> On 22 October 2013 19:32, Oleg Kalnichevski <[email protected]> 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. > Minor API changes in BETA phase should still permissible, especially if they > are confined to classes and interfaces introduced in the previous BETA. That is what I meant by "establishing that a particular change is not likely to be a problem in practice" This information needs to go into the Release Notes. And the announce e-mail should mention that there are API changes which are more fully documented in the RN. > Oleg > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
