-
Notifications
You must be signed in to change notification settings - Fork 1
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
Versioning, releasing, DOI, Zenodo #94
Comments
Ah, I see we already have Zenodo set up, great! Shall we add a comment to the PR template to think about versioning then to finish this off? |
Checklist for PRs:
|
I added a changelog file, accidentally pushed it to master, hope you all agree, if not, feel free to edit. |
Nice that you added the PR checklist to the PR template. |
Do you have experience with that? What does it involve? |
It's actually quite easy, because we already have pip installing properly setup :) Just tried it out (for the first time actually) following this guide, and building a package is just a matter of installing the Then, uploading to PyPI is described here: https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives I think that part can be automated with GitHub Actions as well, since it's done using an API key which can be put in GitHub secrets. |
Following #41 (comment), we should:
Releasing on GitHub with a (semantic) version number is probably a good start for the latter point. Then we just need to think about when we release things. Usually, this would be done after bug fixes (patch version bump), added features (minor version bump) or complete, backwards incompatible rewrites (major version bump).
Let's try to keep these things in mind when we do PRs. One thing we could do for that is make a PR template so that we are automatically reminded every time we do a PR to at least think about whether the PR should bump one of the version numbers.
The text was updated successfully, but these errors were encountered: