RELEASING: ~~first merge PR, then tag~~ clarify where to push the tag

[bluetech]

The previous order is not really possible to perform -- before merging there is no release commit in the MAJOR.MINOR.x branch.

[bluetech]

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.

[nicoddemus]

The previous order is not really possible to perform -- before merging there is no release commit in the MAJOR.MINOR.x branch.

Actually it is, I've always done it that way: even thought upstream still doesn't contain the commit anywhere, by pushing a tag to upstream the commit is now part of it.

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.

[RonnyPfannschmidt]

Dito, I agree with @nicoddemus

[bluetech]

OK got it. But I figure we should still change "tag the release commit in the MAJOR.MINOR.x branch" to "in the release-MAJOR.MINOR.PATCH branch"?

[nicoddemus]

OK got it. But I figure we should still change "tag the release commit in the MAJOR.MINOR.x branch" to "in the release-MAJOR.MINOR.PATCH branch"?

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?

[bluetech]

I must be misunderstanding something but

tag the commit from the build that published the release to PyPI

It's the tag itself that publishes to PyPI so the causality is reversed here?

(the HEAD of MAJOR.MNOR.x branch)

Before merging the release PR, the HEAD of the MAJOR.MINOR.x branch is not the release commit, it is something before. At this point, the release commit is only found in the release-MAJOR.MINOR.PATCH branch. So the needed procedure is to checkout the release branch (the PR opened by pytestbot) and tag the commit there.

[nicoddemus]

I'm sorry, I misspoke. 😬

Before merging the release PR, the HEAD of the MAJOR.MINOR.x branch is not the release commit, it is something before. At this point, the release commit is only found in the release-MAJOR.MINOR.PATCH branch. So the needed procedure is to checkout the release branch (the PR opened by pytestbot) and tag the commit there.

You are absolutely correct.

To be crystal clear:

$ git fetch --all
$ git tag 6.0.2 upstream/release-6.0.2
$ git push upstream 6.0.2

# now merge release-6.0.2 PR

# cheery-pick CHANGELOG changes from `upstream/MAJOR.MINOR.x` to `master`

Perhaps we can reword the instructions to suggest that developers have origin as their fork, upstream as pytest-dev/pytest, and update the instructions accordingly? I prefer this setup because usually tooling defaults to pushing to origin, which is very often the right thing to do.

[bluetech]

@nicoddemus Updated per your comments.

Perhaps we can reword the instructions to suggest that developers have origin as their fork, upstream as pytest-dev/pytest, and update the instructions accordingly?

This is already mentioned at the beginning of the doc ("The git commands assume the following remotes are setup ...")