update development version

[jmitrevs]

Description

The fact that the development branch has a lower version number than our release seems to confuse people. Therefore, I suggest we update the version number of the main branch. The actual version number I am requesting is just a proposal, not necessary the best choice. (I noticed qonnx automates this--maybe something like that would be better.) I just wanted to bring it up.

Type of change

• [x] Other (Specify) -- metadata

Tests

None, other than trying to do pip install -e . in my work area.

Checklist

• [x] I have read the guidelines for contributing.
• [x] My changes generate no new warnings.

[thesps]

In conifer I started using setuptools_scm (here) that extracts a version number from git. So that will include tags, but also each commit on main branch will automagically get a unique version number incrementing from the previous tag (like .devN at the end). It's quite nice and easy to use.

e.g. https://github.com/thesps/conifer/blob/master/setup.py#L9-L10 and https://github.com/thesps/conifer/blob/master/conifer/__init__.py

Edit: and QONNX is using the same. So let's just switch to that as it's so easy?

[jmduarte]

Just a reminder about this PR: https://github.com/fastmachinelearning/hls4ml/pull/479, which I just fixed conflicts for.

Note the issue that it will create temporary tags automatically like 0.5.0.post1.dev184+gc9730ff because the latest upstream tag on main is 0.5.0. The 0.6.0 tag lives on a different branch that is not in the upstream history of main. To prevent this issue in the future, we should probably make sure to tag the next version off of main (i.e.0.7.0).

[thesps]

Just a reminder about this PR: #479, which I just fixed conflicts for.

Good point! Agree we should do it that way

[jmitrevs]

I'll close this and switch to #479, which solves this issue in a better way.