set version using `setuptools_scm`

[jmduarte]

• bump version to 0.6.0
• add GitHub action to automatically bump patch version on merge of PRs

@vloncar @thesps opening this PR for discussion on how to handle automatic version bumping

My thought is it to have a GitHub action to automatically bump patch version on merge of PRs (unless PR has [MINOR] or [MAJOR] in the comment, then we bump the minor or major version as well)

[vloncar]

IMO we should move away from hardcoded __version__ attribute and instead use something like setuptools_scm. That way the git tag becomes the version, and this information is available in the package (through the same attribute). Generating the version information this way gets rid of the problems you may have when switching from master to released version. The way it is currently, if we put 0.6.0 in master we may cause some problems to people switching from released version to master branch. The only way to not have problems is to make sure master is always the latest version (like 99.99.99) but this is very ugly. We're already using the new scheme in the QONNX project (pyscaffold sets this up) and I believe we should do the same here.

[jmduarte]

Good point, that solution is a lot nicer.

I tried to update it by hand, but it may not be correct yet... For some reason, the autodetection of tags seems off, because if I try

python setup.py --version

in the this branch, I get: 0.5.0.post1.dev184+gc9730ff

[jmduarte]

@vladimir I was looking into migrating the whole package using PyScaffold: https://pyscaffold.org/en/stable/migration.html

See, e.g.: https://github.com/fastmachinelearning/hls4ml/compare/master...jmduarte:pyscaffold

What do you think about this approach?

[jmduarte]

OK @thesps @vloncar, I figured out why currently on this branch I get an hls4ml version of 0.5.0.post1.dev133+gef0b82bd. Basically, it's because it looks for the closest parent tag and because we created a separate branch and cherry-picked developments for 0.6.0, that tag is not a parent of the current master branch.

So I'd say this PR is ready to be merged, with perhaps a small change that we should also apply a tag of 0.6.1 somewhere on the current master (could be this commit as well), that way all versions downstream of this commit will be 0.6.1.post1... (until we tag a new version off of master).

This also means we should probably make sure to explicitly tag versions of master. And for "bleeding edge" developments, we should perhaps create a new dev branch

[jmitrevs]

I am partial to switching to version_scheme = "release-branch-semver". This way, if you merge this into main, the main repository becomes hls4ml-0.6.0.dev192+g163e757d.d20221025. We had a release branch for 0.6.0, and I think we can continue that scheme. It's useful for being able to do bug fixes to stable releases. Nevertheless, I am open to other suggestions, since I am not an expert in this area.

[jmitrevs]

Provided the CI tests succeed, I would propose merging this, maybe tomorrow.