-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish version v0.13.0 #113
Comments
CircleCI no longer seems to be working, I don't want to release without working CI. |
@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 |
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. |
@simnalamburt Thanks a lot for the explanation For additional context, the legacy |
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? |
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. |
@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
EDIT: |
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. |
To clarify, I was suggesting using the 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 Thanks for explaining the reasoning behind. Much as I understand legacy users. Can't they stick to It's somehow paradoxical as Thanks a lot and I am willing to help. |
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. |
Hi, I have a day off today, I will check those fails later. |
I've noted that the setup.py had the version bumped to 0.13.0, with the fix supporting redis-py>3 (f59ac38 and c526983).
Are there any plans or obstacles to release a tag and publish this version? Any help needed?
The text was updated successfully, but these errors were encountered: