Release fmf-1.4.0

[psss]

• Use git log --oneline --no-decorate x.y-1.. to generate the changelog
• Update README with new contributors since the last release
• Add a Release tmt-x.y.Z commit with the specfile update
• Create a pull request with the commit, ensure tests pass

Release a new package to Fedora and EPEL repositories:

• Move the fedora branch to point to the new release
• Create a source rpm using the make srpm command
• Enable Fedora kerberos kinit nick@FEDORAPROJECT.ORG
• Change to the fedora rpms git or fedpkg clone tmt
• Check out the rawhide branch git checkout rawhide
• Import the srpm using fedpkg import /path/to/the/srpm
• Restore any files removed by fedpkg if necessary
• Ensure the proposed changes are ok and commit them
• Create a pull request against rawhide from your fork
• After tests pass, merge the pull request to rawhide
• Build the package for rawhide fedpkg build --nowait
• Build package for all active releases git checkout f33 && git merge rawhide && git push && fedpkg build --nowait
• Create a bodhi update for each release git checkout f33 && fedpkg update --type enhancement --notes 'Update title'

Finally, if everything went well:

• Tag the commit with x.y.z, push tags git push --tags
• Manually merge the original release pull request on github (to avoid rebase) git checkout main && git merge --ff-only <release_branch> && git push origin main
• Create a new github release based on the tag above
• If the automation triggered by publishing the new github release was not successful, publish the fresh code to the pypi repository manually using make wheel && make upload
• Close the corresponding release milestone

[LecrisUT]

In the current form, don't forget about fmf/__init__.py:__version__?

Edit: Unless the make wheel will be used for uploading the release and to downstream?