Celery: Release 4.1.0

Or version 5, or 4.1.

Lets just call it the next release.

Also, I want this fix #3903

Yes, merge some of these pull-requests and pop out a new version.

Would either @georgepsarakis, @thedrow, or @auvipy be able to address this issue? It's been over 6 months since last release and it appears that there is a decent amount of changes between 4.0.3 and master (celery, kombu).

We want to release too. The only maintainer that currently has access rights is @ask and he is unavailable due to personal reasons.
If we cannot reach him soon I'm going to reach out to the PyPi folk and have them assign all the packages to us.

@thedrow Thanks for the update. Feel free to reach out if I can help move this along in any way.

Hi everyone,
I got the permissions for all celery packages and we'll start the release cycle as soon as possible.
@alukach If you want to help prepare the release notes for celery.

nice 👍

Glad to hear! You should only have to add release notes for what was merged in after May.

amazing

I just got word that amqp 2.2.0 breaks celery somehow. See https://github.com/celery/py-amqp/commit/942b3aa9cf76d08951fe7baae163b595300cdfe5#commitcomment-23064465
Can anyone test and let us know what is broken?

@thedrow you mean amqp 2.2.1 ? Also latest pull requests should be using the latest amqp release as far as I can understand from Kombu's requirements file. For example here, the tests should be running with the latest amqp version.

@thedrow @auvipy let me know if you need any help with release notes or anything else.

@gabrielpjordao I released 2.2.1 in response. The breakage is gone.

Although not very important, I believe naming the version 4.1.0 would be more suitable given the large amount of changes compared to 4.0.2 (both features and bug fixes).

i do believe so

I just released vine 1.1.4 which is a dependency for the next release.

I just released Billiard 3.5.0.3 as well. I'm going to hold off for a few days with the Kombu and Celery as this is needed to be tested on production .
Billiard 3.5.0.3 fixes some compatibility issues for Python versions below 3.5 and a crash on Windows among other things.

If no one says anything in the next couple of days I'll assume everything is peachy and we'll release Kombu first and then Celery itself.

In case someone wants to contribute https://github.com/celery/celery/pull/3934 requires test coverage in order to be merged and we'd like that to hit 4.1 as well.

https://github.com/celery/celery/pull/3934 is merged with test

ping me after the pypi release. I will create a blog post about the release.

Travis CI in Kombu master is failing. I think the apicheck failures started in this Pull Request, so we need to review the formatting and class references probably to resolve this.

@georgepsarakis made celery/kombu#770 to discuss failure. Trying to get it resolved but could definitely use some input if anyone's feeling keen.

@alukach please check the Pull Request in sphinx-celery. If you could try and verify that my branch solves the issue, it would be great.

Kombu 4.1.0 was released! :tada:
Please test this with your current Celery clusters.

@thedrow Great work! Can we merge celery/sphinx_celery/pull/2 ASAP? It feels like issuing a release with a failing build is bad mojo.

@thedrow Thanks for the merge, now if either you or @georgepsarakis could trigger a retry on https://travis-ci.org/celery/kombu/jobs/255735887, we should have a passing build!

@alukach this won't affect the build job you are mentioning, because the sphinx_celery version used (1.3.1) does not contain the fix.

@thedrow requirements files for both Kombu and Celery use sphinx_celery>=, so if you could please release 1.3.2 of sphinx_celery, it will be used automatically on the next builds. Thanks.

@georgepsarakis Unfortunately I don't have access to that package. @ask forgot to add me to that one.
I'll try to contact him. In the meanwhile keep https://github.com/celery/kombu/issues/770 open.

As of now we're in merge-freeze zone. Unless something very critical pops up on Monday, we'll release Celery 4.1.0.

The only thing that is left is the release notes for Celery. Any volunteers?

@thedrow since we are using requirements files we could use the Github repository directly, if you don't get access any time soon.

I am also adding a comment by @alukach, regarding an easy way to summarize changes, for reference: https://github.com/celery/kombu/pull/764#issuecomment-315963066

@thedrow @auvipy I started this PR https://github.com/celery/celery/pull/4151 , is still a work in progress though.

I just released 4.1.0.
@auvipy or @georgepsarakis Can you please take care of the release announcement on celeryproject.com?
Please make sure to close this issue afterwards.

I am not aware of how celeryproject is deployed. @auvipy could you please do it?

Also, documentation does not seem up-to-date: http://docs.celeryproject.org/en/latest/index.html still shows 4.0.2 . Is there something we can do to update it?

yes I can do the announcement blog.

it's indicating 4.1 http://docs.celeryproject.org/en/master/index.html

Also, pretty minor, but the README (and hence pypi description page) state that:

Celery version 4.0 runs on,

• Python (2.7, 3.4, 3.5)

Version should be bumped to 4.1, and Python list extended with Python 3.6

@auvipy yes, this is for the master branch, see the latest though: http://docs.celeryproject.org/en/latest/index.html

I'm done with the blog post, just need the whats new changlog

here we go http://www.celeryproject.org/news/celery-410-released/

Echoing what @georgepsarakis has reported, v4.1.0 is available (http://docs.celeryproject.org/en/v4.1.0/changelog.html) but the docs still default to 4.0 (http://docs.celeryproject.org/en/latest/changelog.html)

Note, the above issue also exists with the Kombu docs

Looks like latest version is configured to point at the 4.0 branch instead of master in RTD.

@thedrow appears to have owner access to fix that. Admin -> Advanced Setting -> Default branch.

Great work on the release! :tada:

RTD points to the 4.0 branch, simply because that's supposed to be the branch
where maintenance of 4.0.x happens. If it points to master it can quickly get confusing as changes are made that are not in the active version.

Since this is a 4.1 release, that has usually meant creating a new branch for that, but if minor releases are frequent it's reasonable to keep using the 4.0 branch).

Ah, I see. I think there is also the option to set the default version to stable to avoid this confusion, but the separate branch works too!

The automated release process doesn't bump the docs configuration.
I forgot to do that and I'll do that today.