-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update release guide #5274
Update release guide #5274
Conversation
10. Tag the release: | ||
```sh | ||
git tag -a v{0.X.Y} -m 'v{0.X.Y}' | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't the tag still necessary?
Also, I would do the update of the release date in this step, in a extra commit with the message Release v0.X.Y
, and then do the tag on that:
git tag -a v0.X.Y -m 'v0.X.Y'
The advantage is that if the release is delayed but the whats-new.rst
PR is already merged (e.g. because a bug that has to be fixed before the release was found), the date won't be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure - I didn't do that step earlier...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you definitely created a tag, but with a different command, probably? The date was updated in the release notes PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think when I clicked on the github button to make a new release it must have created the new tag then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that could be it. It might be worth keeping that step manual, though: if the build is broken (e.g. because a build dependency is missing / outdated) you don't have to delete / re-create the release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you create a draft release GitHub creates the tag and kicks the normal GA.
When you publish the release (after checking that tests have passed) GitHub kicks the release GA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, good to know, I never used github to create tags. This still feels a bit strange because you'd have to delete / re-create the draft release to rerun the CI (not sure how much of an issue that is), and there's the really minor issue of not being able to set the tag message, which means that the message of the last commit will show up in the overview (hidden behind ...
).
Looks great! I'm happy to see my hard work be removed! |
Shall we merge? |
* upstream/master: combine keep_attrs and combine_attrs in apply_ufunc (pydata#5041) Explained what a deprecation cycle is (pydata#5289) Code cleanup (pydata#5234) FacetGrid docstrings (pydata#5293) Add whats new for dataset interpolation with non-numerics (pydata#5297) Allow dataset interpolation with different datatypes (pydata#5008) Flexible indexes: add Index base class and xindexes properties (pydata#5102) pre-commit: autoupdate hook versions (pydata#5280) convert the examples for apply_ufunc to doctest (pydata#5279) fix the new whatsnew section Ensure `HighLevelGraph` layers are `Layer` instances (pydata#5271)
Thanks @TomNicholas |
* upstream/master: Update release guide (pydata#5274) combine keep_attrs and combine_attrs in apply_ufunc (pydata#5041) Explained what a deprecation cycle is (pydata#5289) Code cleanup (pydata#5234) FacetGrid docstrings (pydata#5293) Add whats new for dataset interpolation with non-numerics (pydata#5297) Allow dataset interpolation with different datatypes (pydata#5008)
Updated the release guide to account for what is now automated via github actions, and any other bits I felt could be clearer.
Now only 16 easy steps!
pre-commit run --all-files
whats-new.rst