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.

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]

Reply via email to