René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support PEP 440 versioning","articleBody":"## Description\r\n\r\nIt would be useful to support [PEP 440](https://peps.python.org/pep-0440/) versioning alongside, or instead of, semantic versioning (they are similar, with subtle differences in identifiers).\r\n\r\n## Use cases\r\n\r\nPoetry 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.\r\n\r\n## Possible implementation\r\n\r\nCurrently, 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`).\r\n\r\nIn 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`).\r\n\r\nPEP 440 also provides [regular expressions](https://peps.python.org/pep-0440/#appendix-b-parsing-version-strings-with-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. \r\n","author":{"url":"https://github.com/thearchitector","@type":"Person","name":"thearchitector"},"datePublished":"2022-06-09T16:04:44.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":17},"url":"https://github.com/455/python-semantic-release/issues/455"}