On Sun, 2013-10-27 at 14:08 +0000, sebb wrote: > On 27 October 2013 13:39, Oleg Kalnichevski <[email protected]> wrote: > > On Sat, 2013-10-26 at 12:31 +0100, sebb wrote: > >> 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. > >> > > > > 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: [email protected] For additional commands, e-mail: [email protected]
