Release fmf-1.5.0

[psss]

Follow the steps below to create a new major or minor release:

• Update README.rst with new contributors since the last release
• Review the release notes in releases.rst, update as needed
• Add a Release x.y.z commit, empty if needed: git commit --allow-empty -m "Release x.y.z"
• Create a pull request with the commit, ensure tests pass, merge it

Create a new github release based on the tag above

• Move the fedora branch to point to the new release
• Tag the commit with x.y.z, push tags git push --tags
• Create a new github release based on the tag above
• Mention the most important changes in the name, do not include version
• Push the “Generate release notes” button to create the content
• Publish the release, check Fedora pull requests, make sure tests pass and merge
• Close the corresponding release milestone

[martinhoyer]

Just a few nitpicks :) Thanks!

[psss]

So, the release action failed with:

pipx: error: argument command: invalid choice: 'hatch'

@LecrisUT, why pipx is used for running hatch build? Is the correct syntax pipx run hatch build?

[LecrisUT]

I forgot I had it like that. pipx is just to avoid a pip install command. Should have replaced it with build-and-inspect-python-package and always run it.

Yes, the pipx run should have been there

[martinhoyer]

I forgot I had it like that. pipx is just to avoid a pip install command. Should have replaced it with build-and-inspect-python-package and always run it.

Yes, the pipx run should have been there

This looks pretty good.

As for the pipx vs pip, etc...
Ultimately doesn't matter, especially since it's being run only on release. Also, depends on what's already available on ths image.

I wouldn't be afraid of just doing pip install hatch here. But yeah hynek's action looks cool.

Anyway, for 1.5.0 - manual hatch publish?

[psss]

There might be more surprises on the way, let's try the automation until the end. I've updated the command in #268 and will re-create the release again.