Support PEP 440 versioning
See original GitHub issueDescription
It would be useful to support PEP 440 versioning alongside, or instead of, semantic versioning (they are similar, with subtle differences in identifiers).
Use cases
Poetry enforces PEP 440. pip
, pypi
and setuptools
all will or currently do support it, and may also require it. Since this package is intended for python specifically, it would make sense to support versioning that adheres to the accepted format.
Possible implementation
Currently, there is a --prerelease
option. In PEP 440, you can also have post releases, dev releases, and local versions. It would be nice / required to have those options as kwarg flags as well (like --postrelease
, --dev
, --local
).
In terms of prerelease
, the prerelease_tag
would have to go from accepting any input to accepting only those valid in the spec (alpha
, beta
, pre
, preview
, a
, b
, c
, and rc
).
PEP 440 also provides regular expressions that can be used to check and extract existing version identifiers, which could be useful in automatically determining the next version of a valid release.
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:7 (2 by maintainers)
Top GitHub Comments
Ah yes - the “.” before the revision specifier, sorry for not getting that sooner. I’ve hit the same pain before, I agree that a
--pep-440
would be valuable.An alternative might be to have a
--version-compat=
flag which can be set topython
to achieve the same goal - but with the advantage of being able to allow additional values down the line if another language has a similar quirk (admittedly I don’t know of one offhand). What do you think?This feature request has been labelled as help wanted since there has been no activity in the last 3 weeks. It will not be closed.