Repository navigation
Support PEP 440 versioning #455
Description
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.
Activity
bernardcooke53 commentedon Aug 23, 2022
@thearchitector would this requirement be met by being able to configure
prerelease_tagon 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.tomlfor Rust projects in the future - but Rust projects won't need to know/care about PEP 440Aaryia commentedon Aug 31, 2022
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.Nis 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.ZtagNwhere tag could be one of many,rc,devor others, which can be covered with the use ofprerelease_tag.It would be nice to have a
--pep440option or similar to natively support compatibility with PEP 440 prerelease versions.bernardcooke53 commentedon Aug 31, 2022
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-440would be valuable.An alternative might be to have a
--version-compat=flag which can be set topythonto 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?Aaryia commentedon Sep 1, 2022
I 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.)stefanondisponibile commentedon Jun 18, 2023
What about just making the
-and.parts configurable?I think here and here, but might need to have a closer look.
So one can have full control over the whole release name and go from
X.Y.Z-tag.N(PEP440🚫 ) toX.Y.ZtagN(PEP440✅ ) here.Do you see any drawbacks?
Vichoko commentedon Jul 31, 2023
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.
thearchitector commentedon Aug 1, 2023
i like the
version-compatconcept (though open to other, possibly clearer, names). I can draft a PR and see how things turn out.github-actions commentedon Mar 26, 2024
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
github-actions commentedon Nov 6, 2024
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?
codejedi365 commentedon Nov 9, 2024
Need to update & complete the PR and this will become reality. Hopefully over the upcoming month.
github-actions commentedon Jan 9, 2025
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?
codejedi365 commentedon Jan 9, 2025
Still under development, PR is a little stagnant at the moment as I have been working other things.
github-actions commentedon Mar 11, 2025
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?
codejedi365 commentedon Apr 20, 2025
Still in development, but progress has stalled.
github-actions commentedon Jun 19, 2025
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?