Publish version v0.13.0

[sibson]

Publish version v0.13.0

[sibson]

To clarify, I was suggesting using the git+https syntax with pip rather than git as a package manager.

I agree a package on pypi indicates a level of stability that git master doesn't, hence why I wasn't willing to release without CI coverage. #114 did the heavy lifting to add that and I've added #115 to check all combinations of package dependencies that could cause issues. As you can see in the test results, there is some incompatibility with Celery 3, that needs to be resolved. I know Celery 3 is old but I also know there are production users who are unable to upgrade to Celery 4. So a new release would break RedBeat for them.

My plan is to get 0.13 out once master is stable, then assuming no issues, re-release that as a 1.0 line. Then I'll merge the existing PR backlog, that includes various breaking changes into a 2.x line and push out a release. I expect I'll drop Celery 3 and py-redis 2 support in the 2.x line.

[sibson]

https://pypi.org/project/celery-redbeat/0.13.0/

[simnalamburt]

Looks like owner of redbeat just added Circle CI 2.0 support few hours ago 9b7d0bf

As far as I know there's nothing left blocking the 0.13.0 release. Just let's give him some time.

[sibson]

CircleCI no longer seems to be working, I don't want to release without working CI.

[simnalamburt]

@sibson It's because redbeat still uses CircleCI 1.0 https://circleci.com/sunset1-0/

Upgrading it with CircleCI 2.0 or merging #114 will be helpful

[simnalamburt]

I think it's because that most libraries assume that only the version uploaded to PyPI is a stable release, and that the version in the master branch is considered a development version and that there may be a bug.

In the case of Redbeat, using the master branch may not be a problem at all. However, from the user's point of view, you can not be sure whether it's OK to use master branch or not.

[aydumoulin]

@simnalamburt indeed the user expects stable releases through a use of pypi.

I will add that the package manager pip works better with pypi packages than git ones.

For instance let a project A specifying a library B bearing a dependency to a git package (say redbeat). pip handles double level dependency via pypi packages but not git ones and redbeat will have to be specified in A instead of B which breaks responsibility principle and complicates maintenance.

celery-redbeat==0.13.0
git+https://github.com/sibson/redbeat.git@0510ee571cf0abd263f0f9b34cfc838b261b009f#egg=celery-redbeat

EDIT: celery-redbeat 0.13.0 works smoothly with celery 4.3.0, kombu 4.5.0 and redis 3.2.1

[laixintao]

Agree with @aydumoulin , using pip is more common that using git as package manager.

Just release a new version would be better. Actually I think every changes of code should be released by a new version. https://semver.org/

I would like to help if there is any problem with releasing.

[aydumoulin]

@sibson Thanks for explaining the reasoning behind.

Much as I understand legacy users. Can't they stick to 0.12.0? At some point all software projects drop backward compatibility. They won't see a break they will just be stuck at a final version.

It's somehow paradoxical as redbeat is the package holding celery users such as me to move to the latest version. I am looking forward for the issue of this 1.0 release!

Thanks a lot and I am willing to help.

[aydumoulin]

Upgrading it with CircleCI 2.0 or merging #114 will be helpful

Looks like #114 got merged. What else could prevent a release?

[aydumoulin]

@simnalamburt Thanks a lot for the explanation

For additional context, the legacy redis<3.0 dependency drags along kombu and celery. Indeed the latest version of celery introduced a fatal support break.

[sibson]

It seems like a release is a pressing matter for a number of people and I'd like to better understand why that is. I've not kept up with the python packaging ecosystem, so please forgive if I'm asking a silly question or making bad assumptions. I have been assuming that people would be able to pin their requirements to a GitHub commit, thereby getting the latest code in a repeatable fashion without a release. Is that not possible? Unacceptable? Or are there other factors I should be considering?

[sibson]

There are a few test failures holding up the release. I suspect they are mechanical rather than semantic, but I've not had a chance to look into them. Once the tests are green I'll cut a release.

[laixintao]

Hi, I have a day off today, I will check those fails later.