-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
RELEASING: ~~first merge PR, then tag~~ clarify where to push the tag #7741
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
Conversation
RELEASING.rst
Outdated
|
||
#. Tag the merge commit in the ``MAJOR.MINOR.x`` branch and push it. This will publish to PyPI:: |
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.
Here I say to tag the merge commit but can also tag the release commit itself. The merge commit seems more appropriate to me, but I see previous releases tagged the release commit. Going to keep it as the merge commit but can change it.
Actually it is, I've always done it that way: even thought I really prefer this workflow, as we are tagging exactly the commit which was released; doing that after the merge is problematic, as in the time between the release branch being created and the actual release, other commits might have been merged. |
Dito, I agree with @nicoddemus |
OK got it. But I figure we should still change "tag the release commit in the |
I find the former more precise (we tag commits, not branches), but perhaps "tag the commit from the build that published the release to PyPI (the HEAD of MAJOR.MNOR.x branch)"? WDYT? |
I must be misunderstanding something but
It's the tag itself that publishes to PyPI so the causality is reversed here?
Before merging the release PR, the HEAD of the |
I'm sorry, I misspoke. 😬
You are absolutely correct. To be crystal clear:
Perhaps we can reword the instructions to suggest that developers have |
791edba
to
0274155
Compare
@nicoddemus Updated per your comments.
This is already mentioned at the beginning of the doc ("The git commands assume the following remotes are setup ...") |
The previous order is not really possible to perform -- before merging there is no release commit in the
MAJOR.MINOR.x
branch.