Support PEP 440 versioning #455
Description
Activity
@thearchitector would this requirement be met by being able to configure prerelease_tag on a per-branch basis? It sounds like you want to create different prerelease formats based on (I'm guessing) the branch you're using?
I don't think restricting to PEP 440 versions only is a good idea - although PSR is a Python tool, nothing precludes it from running against projects in other languages. For example it would be a small leap to support config in Cargo.toml for Rust projects in the future - but Rust projects won't need to know/care about PEP 440
I am finding the tool really useful in theory, but I am not able to use it for work projects due to the lack of support of PEP 440...
From what I gather, the format X.Y.Z-tag.N is not at all compatible with PEP 440, or at least is not considered canonical. It keeps us from publishing prerelease packages using PSR which is a shame.A supported format would be X.Y.ZtagN where tag could be one of many, rc, dev or others, which can be covered with the use of prerelease_tag.
It would be nice to have a --pep440 option or similar to natively support compatibility with PEP 440 prerelease versions.
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 to python 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?
Reacted by Martin BABEAU and David WaterworthI do think a --version-compat= flag allows for better future-proofing, as others might want to use it if there are weird standards in other languages, or even if python decides to change the versioning schema (offhand, I can only think of the MAVEN convention which differs slightly, like the PEP 440.)
Python Semantic Release pre-releases aren't compatible with Poetry because project.tomlrequires PEP440.
I really hope there would be a way to configure the version format.
Reacted by David Waterworth and Constantin Hüttereri like the version-compat concept (though open to other, possibly clearer, names). I can draft a PR and see how things turn out.
This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.
9 remaining items
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Need to update & complete the PR and this will become reality. Hopefully over the upcoming month.
Reacted by Stefano, David Waterworth, Constantin Hütterer and Matt GebertIt has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Still under development, PR is a little stagnant at the moment as I have been working other things.
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Still in development, but progress has stalled.
Reacted by Matt GebertIt has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Description
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.