I've gone through the commits since the last tag and added them, grouping the minor tweaks/fixups and doc changes. I think I've got everything.
Incidentally I've left a question in #689 but that needn't prevent release.
* Prevent spurious exception on Resource.resize(0)
`Resource.resize()` raises an exception if the pool is in use and the new size is smaller than the old size. However, it also raises this exception when the new size is zero, which should correspond to disabling the pool. Instead of shrinking the pool to zero and releasing all resources, we can simply dequeue all resources and forget about them.
* Add test for removing pool limit when in use
* Fixes#791
* Changing to recommended patch by @georgepsarakis
* Revert "Fixes #791"
This reverts commit 5593505dd9.
* Updated to make tests pass
* Made _ensure_str a private function
* Code formatting for flake8
* Added a mock of the newstr and newbytes classes to create a failing test that simulates the issue with using python-future under 2.7.
* Require Redis 2.10.4 or greater
The Redis transport uses the `can_read`'s `timeout` parameter. This parameter was added in 2.10.4.
* Bump the version to what Celery uses
* Fix infinite loop in create_loop
fixes https://github.com/celery/celery/issues/3712
Before handling the todo items we "freeze" them by copying them aside and clearing the list.
This way if an item in the todo list appends a new callable to the list itself it will be taken care of in the next iteration of the parent loop instead of producing an infinite loop by adding it to the list we're running on.
* Changed the test to be aligned with the new implementation
* passing flake8
* Avoid copying results with each iteration of the async loop.
* Pop instead of slicing.
* fixed: todos -> todo, fixed test to use MagicMock so we can use the len() method
* MagicMock not supported in 2.7, implemented __len__ on Mock instead
* added entry to changelog
Celery 4.0.2 passes the `multiple` keyword argument to `basic_ack`.
This did not used to occur with 3.1.20- so this change is only being
merged into the 4.0 branch. The desired functionality of this param is
documented here [0], but the Qpid transport uses UUIDs as the
delivery_tags so we don't have a record of the sequential messages
required to implement this. We use UUIDs as the deliver_tag to avoid
Issue #563.
With the functionality for the `multiple` parameter not implemented, an
AssertionError is raised if Celery attempts to meaningfully use the
`multiple` parameter with the Qpid transport. A developer or user who
encounters this AssertionError should file a bug with Kombu.
[0] http://amqp.readthedocs.io/en/latest/reference/amqp.connection.html#amqp.connection.Connection.Channel.basic_ackcloses#699
Omer Katz