On 8 June 2016 at 15:07, Ken Giusti <[email protected]> wrote: > Robbie - > > ----- Original Message ----- >> From: "Robbie Gemmell" <[email protected]> >> To: [email protected] >> Sent: Tuesday, June 7, 2016 4:56:56 PM >> Subject: Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4) >> >> Is the behaviour a regression, or has it always been that way? If its >> the latter then I think its simply a good addition to a list of things >> worthy of a swift followup release, rather than a reason to hold back >> this one. >> > > Good point - no it is not a regression. > > But it is an ambiguity in the behavior that is visible to the clients that > will likely result in clients violating the AMQP 1.0 spec (i.e. resending w/o > proper delivery count or resending to a node that cannot process the message). > > No I don't want to hold up the release. I agree it's been too long since the > last release (but given the major refactor that has occurred it is > understandable why it has taken so long). But I don't want to let this issue > remain open for too long once a fix is available. > > I haven't found any other issues with the RC4 candidate. > > If the consensus is to ship 0.6.0 without a fix I'll rescind my -1 but I'm > going to call for a 0.6.x release if 0.7.0 doesn't ship within a couple of > weeks after a fix is made available. > > Is this a reasonable compromise? > > -K
Yes, I think doing a 0.6.1 (or however many 0.6.x as are appropriate to resolve similar issues as they arise) if 0.7.0 is more than a couple weeks away seems like a good approach. It almost seems like the final digit in the versions could be useful :) Robbie > >> There will be other things requiring fixes and as people discover >> those we can and should do additional releases as appropriate to fix >> them. It looks to be almost 9 months since the last Dispatch release, >> its time to get a new one out and then do some more after that. >> >> I've said this before, but I think its worth repeating. In general we >> are guilty of taking too long to put out releases, often coupled with >> having putting too much in them, then putting even more things in to >> avoid them waiting around for the next slow release. The trouble is, >> the more often releases are delayed to fit in yet another thing, then >> the more often people will feel the need to fit yet more into it, and >> the longer people will put off testing the candidate builds due to >> expectation there will still be more of them to come, and the later we >> might find actual blockers as a result, and the further needless >> respins there are. The net result is fewer releases that can often end >> up being overly annoying and further encourage doing less of them. >> >> It takes us no more time and effort (probably even a good bit less) to >> do multiple releases in a given reasonable time period than it does to >> respin one over and over before release, but short of breaking API >> changes to consider its generally going to be nicer having the >> additional releases. >> >> Robbie >> >> On 7 June 2016 at 20:57, Ken Giusti <[email protected]> wrote: >> > -1 - Don't release RC4 because of >> > https://issues.apache.org/jira/browse/DISPATCH-366 >> > >> > Sorry to be the party pooper, but this seems serious enough to block the >> > RC. >> > >> > If this isn't fixed we risk clients re-sending messages with the improper >> > delivery-count value. >> > >> > >> > >> > >> > ----- Original Message ----- >> >> From: "Ted Ross" <[email protected]> >> >> To: [email protected] >> >> Sent: Monday, June 6, 2016 5:32:14 PM >> >> Subject: [VOTE] Qpid Dispatch Router 0.6.0 (RC4) >> >> >> >> This is the vote thread to approve RC4 as the final Dispatch Router 0.6.0. >> >> >> >> Given that this is a significant release in terms of features and >> >> functionality, I think we should get it released. >> >> >> >> I understand that there are a number of open issues with this candidate, >> >> the most worrisome being DISPATCH-358. This issue involves intermittent >> >> crashes, but to this point it has been unreproducible outside of the >> >> reporter's test environment. >> >> >> >> My proposal is to go forward with the release, get the new functionality >> >> out officially, and continue to close out the issues that are >> >> outstanding. If we reproduce and fix DISPATCH-358, we can turn a 0.6.1 >> >> on the release branch, or wait for 0.7.0 (which should be much shorter >> >> in duration than 0.6.0). >> >> >> >> Please weigh in with your opinion and your vote: >> >> >> >> +1 - Release RC4 as Qpid Dispatch Router 0.6.0 >> >> -1 - Don't release RC4 because of _____________ >> >> >> >> Thanks, >> >> >> >> -Ted >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > -- >> > -K >> > >> > --------------------------------------------------------------------- >> > 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] >> >> > > -- > -K > > --------------------------------------------------------------------- > 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]
