ENH: Respect tags with .postN in pep440-pre style#261
Conversation
| post-release version number (or -1 if no post-release segment is present). | ||
| """ | ||
| vc = str.split(ver, ".post") | ||
| return vc[0], int(vc[1] or 0) if len(vc) == 2 else -1 |
There was a problem hiding this comment.
It might be better if the else case returned None instead.
|
@effigies is there anyone in particular I should ping to get their thoughts on this, desired changes, etc? It would be nice to get the versions rendered with pep440-pre a bit closer to conforming to the PEP440 standard when the closest tag already has some release segments that are currently just assumed to never be present. |
|
I think I'm the closest person right now. I'll try to have a look soonish. |
|
There are a few packages I've been holding off sending PRs to that would use this modified version of the renderer -- if this PR seems like it is moving somewhere soon then I'll continue to hold off, since I'd much rather the changes get upstreamed to versioneer than maintaining my own fork. (Of course if there's no chance it will get merged, I'd rather just hear sooner than later so I can figure out what alternative to go with.) |
effigies
left a comment
There was a problem hiding this comment.
Thanks for the bump. This looks entirely reasonable to me. I don't have a strong opinion about the -1 vs None issue. If you would prefer to change it, feel free. Otherwise I think this is good to merge.
|
Thanks! I'll update the docs to mention the new behavior. I think I'll make the |
|
LGTM. Happy to merge if you're ready. |
.postN in pep440-pre style
tl;dr -
pep440-predoesn't check if the closest tag already contains a post release segment, resulting in a version string that PyPI rejects because there are multiple post release segments. The proposed change detects if a post release segment is present in the tag, and makes versioneer create dev releases for the next postN version instead of always post0.For a number of projects (e.g. cmake, ninja), the main release segment of the version string matches the version number of the tool being packaged, and the post-release segment is used to indicate updates that just change the pip package but not the underlying tool.
Picking a style to use with versioneer that fits the tag/version workflow is tricky because none of the ones that append a
+<local version>string can be uploaded to PyPI. The closest match to this versioning scheme ispep440-pre, but because new releases use tags in the formvX.Y.Z.postN, versioneer decides the version will be in the formvX.Y.Z.postN.post0.devN, which PyPI rejects because there are multiple post-release segments.In addition, if the last release was
vX.Y.Z.post0, the next post release would bevX.Y.Z.post1, so versioneer dev versions should be in the formvX.Y.Z.post1.devN. (This has the downside of if the next release won't be apostrelease -- but that same downside is true of the current implementation of thepep440-prestyle.)I've modified the
pep440-prestyle to check if a post release segment exists in the tag, and if so to increment thepostNpart of the rendered version to the appropriate value for the "next" post release. I think this handles the cases described above better than the existingpep440-preimplementation without breaking backwards compatibility. The one downside with what I have right now is it expects that tag to be the "normalized" form of the tag in that it doesn't handle synonyms likerev,r, or the alternative-,_, no segment separator, or-only variations of specifying a post release.Any thoughts on making these changes to the existing style, or adding a new
pep440-pre-noduplicatepoststyle? I think there are a few other of thepep440styles that could also be updated to better handle a closest version tag that already includes pre/post/dev release segments.