Version number for main branch install is `8.15.0`

[andreas-el]

This is what we currently have in komodo bleeding:

(rhel7-bleed-env + bleeding-py38-rhel7) [andrli@st-linrgs176 ~]$ pip list | grep -E "libecalc|ruamel|typer"
libecalc                             8.15.0
ruamel.yaml                          0.18.6
ruamel.yaml.clib                     0.2.8
typer                                0.12.3
(rhel7-bleed-env + bleeding-py38-rhel7) [andrli@st-linrgs176 ~]$ pip check
No broken requirements found.

But the version installed certainly isn't 8.15.0

(rhel7-bleed-env + bleeding-py38-rhel7) [andrli@st-linrgs176 ecalc]$ git describe --tags
v8.15.0-40-gab43bd7

This causes some confusion, since pip wants to upgrade the package to version 8.15.6 which is actually older than what we currently have from main.

[TeeeJay]

@andreas-el that is correct. we have a separate release branch for every major.minor version, and only the release branch is tagged with updated patch versions.

main represents 8.16-snapshot or something like that, since the release has not been made and it is not given that it will be 8.16 or 9.0.

how do you suggest that we do? adding 8.15.6 to main is also not correct, since main has other updates except for bugfixes/patches that is on the 8.15 release branch.

[andreas-el]

@andreas-el that is correct. we have a separate release branch for every major.minor version, and only the release branch is tagged with updated patch versions.

main represents 8.16-snapshot or something like that, since the release has not been made and it is not given that it will be 8.16 or 9.0.

how do you suggest that we do? adding 8.15.6 to main is also not correct, since main has other updates except for bugfixes/patches that is on the 8.15 release branch.

@TeeeJay There are many ways to resolve something like this, many include using setuptools_scm.

My first thought would be to consider tagging the first available commit after the release/v8.15 branch was made with something along the lines of v8.16.0-b0 and make sure this is set as a pre-release tag to avoid pushing to pypi. This way main seem newer than the released tags for pip and if using setuptools_scm you can then have relative distance to that commit, e.g. v8.16.0.dev40.. I guess only adding the pre-release tag will resolve this issue we face.

I'm rather coloured by how we do this in the ert repo though.