Skip to content

[Backport #6914] Revert "[parametrize] enforce explicit argnames declaration (#6330)"#6919

Merged
nicoddemus merged 1 commit intopytest-dev:masterfrom
nicoddemus:backport-6914
May 16, 2020
Merged

[Backport #6914] Revert "[parametrize] enforce explicit argnames declaration (#6330)"#6919
nicoddemus merged 1 commit intopytest-dev:masterfrom
nicoddemus:backport-6914

Conversation

@nicoddemus
Copy link
Member

I realize now that I should have done the other way around: revert the original PR on master, and then backport to 5.4.x.

Either way, what should we do with the CHANGELOG on backports like this one?

Revert "[parametrize] enforce explicit argnames declaration (pytest-dev#6330)"
@nicoddemus nicoddemus requested a review from bluetech March 13, 2020 13:52
Copy link
Member

@bluetech bluetech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's more of a "forward" port :)

I haven't checked extensively -- assuming it's just a revert and same as #6914, LGTM.

Either way, what should we do with the CHANGELOG on backports like this one?

I guess we need to decide with to do with the changelogs anyway. I'll open an issue about this (and other things about the release maybe) later.

Also this PR is not a good test-case, because it went in the wrong way (first to release branch and then to master).

For now, what I'd do is:

  • Remove changelog from this PR & merge it.
  • Once the patch release containing this is done, cherry-pick the release PR to master (which includes the doc updates & changelog).

@nicoddemus
Copy link
Member Author

I guess it's more of a "forward" port :)

Heh yep. 😅

Also this PR is not a good test-case, because it went in the wrong way (first to release branch and then to master).

Definitely, my bad, I realized my mistake too late.

Remove changelog from this PR & merge it.
Once the patch release containing this is done, cherry-pick the release PR to master (which includes the doc updates & changelog).

5.4.1 has been released already, so aren't those two suggestions the same thing? Both would end with the change on master (unless I'm missing something).

@bluetech
Copy link
Member

5.4.1 has been released already, so aren't those two suggestions the same thing? Both would end with the change on master (unless I'm missing something).

My thinking is, that the changelog will be included in 5.4.2, and we will cherry-pick the 5.4.2 changelog to master (like 68d4b17), then if this PR changelog is also included in master, then it will eventually be duplicated in 5.5.0. But I may be missing something too :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants