Improvements of release flow - auto-categorize new PRs, update docs, etc

[ltalirz]

problems

I notice the new version suggested by the release drafter is determined directly by the category labels - e.g. if any of the features since the last release was a feature, the suggested version is the next minor version, even if at the end a maintainer suggested only to bump the patch version for the next release.

This can lead to inconsistencies and I already once made a mistake, changing only the name of a release from v0.6.0 to the patch version v0.5.7, but forgetting also change the tag. This resulted in it creating an extra tag v0.6.0 pointing to the same commit as v0.5.7. It's not a major problem since the version deployed to PyPI depends on the version in the source code and so is still v0.5.7 as intended, but ideally we design the flow in such a way that such inconsistencies cannot arise.'

Edit: If we want to follow the versioning scheme suggested by the release drafter, we should use a "release" label, rather than a patch/minor/major label.
I think that could be a reasonable flow (and we can keep the patch/minor/major label for cases when we want to explicitly ask for a different version).

suggestions for improvement

I believe the release drafter can actually automatically add category labels to new pull requests based on the name of the branch, which then autoselects the correct new version.
We should make use of this feature and document how one should name branches in order to take advantage of it, as well as when and how to use the version bump labels (see also #286 (comment) )

[Atilaac]

This is easily solvable; we just need to agree on proper PR naming. As you said, the release drafter has this as a feature and can read it directly from the branch name. A suggestion is to use the Conventional Commit standard to classify changes

feat: for a new feature.
fix: when a bug is fixed.
docs: for documentation changes/additions/deletions.
style: for formatting.
refactor: when a refactoring is done.
chore: when updating or adding configs, etc.
perf: for performance-related modification, e.g., making functions faster.
ci: for continuous integration stuff.
EDIT:
test: for tests.

You, @ltalirz, are always following these conventions.

[ltalirz]

Most of this has been implemented in the meanwhile - the automatic tagging of new PRs based on branch names works.

I've added #337 that updates the docs to reflect this + implements my suggestion of a "release" label (we could then get rid of the semver labels).

[ltalirz]

PR is merged, closing