Open ktbarrett opened 3 years ago
A towncrier based picker is still on the todo
This is a general problem, towncrier was just an example. I have no interest in a towncrier based picker.
The next version guessing algo assumes it will bump the minor version. How do I get it to "guess" a major version bump instead?
Tag MAJOR.0.0.DEV
That doesn't work unfortunately.
I tagged the first commit that starts the 2.0 development series on master with "v2.0.0.dev" and then created another commit on top of it on master:
commit a57651cd590fe4261223d48368ba06275c6a886e (HEAD -> master)
Author: Philipp Wagner <mail@philipp-wagner.com>
Date: Wed Mar 3 19:07:43 2021 +0000
asomething
commit 9fe131d93f31438d032307f70096fac797af78e0 (tag: v2.0.0.dev, origin/master, origin/HEAD)
Author: Philipp Wagner <mail@philipp-wagner.com>
Date: Tue Feb 23 00:03:17 2021 +0000
Generate release notes for v1.5.0
That causes setuptools_scm to increment the version to 2.1.0:
❯ cocotb-config --version
2.1.0.dev1+ga57651cd
It looks like we end up at https://github.com/pypa/setuptools_scm/blob/b8451688b9cb295136c0154c7c59c25a9d88f844/src/setuptools_scm/version.py#L308 which always increments the minor version, even if the version ends in ".dev" or ".dev0".
Indeed, the version scheme doesn't seem to match you flow
They ough to be documented better
I didn't see anything in the documentation about how to get setuptools_scm to decide the next version number will bump the major version number (1.5 -> 2.0.devN###). Our setuptools_scm generated version number will be 1.6.0.dev### using the
release-branch-semver
method, which is picked up by towncrier for the release notes showing the wrong next version. And it leads to inconsistencies with Sphinx comments relating to change in behavior in versions.. versionchanged:: 2.0
.