Merge pull request #7550 from pytest-dev/release-6.0.0

[nicoddemus]

No description provided.

[nicoddemus]

(Going ahead and merge this to complete the release)

[nicoddemus]

Oh I just realized the release process doesn't work from releases made directly from master, as is the case with major/minor releases... or did I miss something?

[bluetech]

Not sure I understand, can you explain what doesn't work?

[nicoddemus]

Sorry, should have been more specific: our master still contain the changelog entries from 6.0.0.

[bluetech]

I think in the days of old (i.e. previous release) you cherry-picked the release commit from the stable branch to master. It's a bit annoying but I don't see a way around that.

[nicoddemus]

Hmmm can't we always merge back from release -> master after each release (for example merge 6.0.x back into master after 6.0.0, 6.0.1, and so on)? The duplicated commits shouldn't cause problems.

[bluetech]

I suspect they will cause problems -- sometimes things drift and the backport is not a clean application of the original commit. Is there a reason to prefer a merge over a cherry-pick?

[nicoddemus]

Hmm I think the problem is that we explicitly discard the cherry-pick results for the changelog folder:

git fetch --all --prune
git checkout origin/master -b cherry-pick-release
git cherry-pick --no-commit -m1 origin/MAJOR.MINOR.x
git checkout origin/master -- changelog  # <- discards the changelog deletions
git commit  # no arguments

I guess it makes sense to keep those changes so they don't appear in the next major/minor again?

[bluetech]

Hmm yes, I think this is just a mindless copy/paste (by me) from the old workflow. I think we should remove this line now.

[nicoddemus]

No worries, let me amend that and fix the changelog entries (I will do a merge for now, but I agree in general the cherry-pick is the correct approach).