@obestwalter I think because you released and tagged the feature branch. This messes up our versioning because setuptools-scm still thinks master is 3.0.0rc3...
Yes, I also noticed that. I cherry picked the commit but did not move the tag. I will have to do some homework to figure out how to do that correctly. Might not be such a fantastic idea to have that release branch after all.
Thinking through this I think this is in general limitation of feature branches. When creating release branches maybe we should in parallel mark the master alpha of next version: e.g. 3.1a?
This would be one way. I did not look into it further yet, but otherwise we'd actually have to move the tag from the branch to master, which then breaks the versioning on the branch and lies about what was the actual commit from which the release was cut.
Yeah, that's why I would force creation of an alpha. CPython does it similarly.
I'd say let's use the alpha version approach then and let's tag 558f18b74e3ecfc203963165fcc8af15ba6673d4 - the cherry picked changelog update for 3.0 with 3.1a, ok?
3.1 went out part of the master, let's leave it on the feature branch as it is :+1:
Most helpful comment
I'd say let's use the alpha version approach then and let's tag 558f18b74e3ecfc203963165fcc8af15ba6673d4 - the cherry picked changelog update for 3.0 with 3.1a, ok?