A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.
A release version segment is either a . separated sequence of integers or a sequence of integers separated by zero or more additional - or _ characters. Public versions MUST comply with the following scheme: [N!]N(.N)*[{a|b|rc}N][.postN][.devN] where all the elements in square brackets are optional. Pre-release versions bear a a, b, or rc prefix followed by an integer. Examples: 1.0.0a1, 1.2.3rc1, 1.2.3, 1.2.3.post1, 1.2.3.post2.dev3.
We have been compliant with PEP 440.
However, we are non-compliant with semver by tagging releases as v0.12.1b11 (should be v0.12.1-beta.11). This has led to minor extra work in CI since the version-checker action we used started requring following the spec strictly, and the old version has lots of deprecation warnings. We forked the action, but we'd rather return to using the upstream version.
The PEP 440 and semver specs are incompatible due to how alpha/beta/rcs need to be written: PEP440 disallows dashes, semver requires them. Apart from that, they both allow for extended metadata + suffixes (Local version identifiers in PEP440 terms).
Not sure what's the right call here. It's a little bit of work changing build scripts etc, but work is coming anyway with the extra maintenance from non-complicance as semver has better support in non-Python tooling.
If we decide it's a good idea, we could do the switch for v0.13.0.
Not in a rush to make a decision, but I've been thinking about it for a while, and needed to write it down.
According to semver spec:
According to PEP 440:
We have been compliant with PEP 440.
However, we are non-compliant with semver by tagging releases as
v0.12.1b11(should bev0.12.1-beta.11). This has led to minor extra work in CI since the version-checker action we used started requring following the spec strictly, and the old version has lots of deprecation warnings. We forked the action, but we'd rather return to using the upstream version.The PEP 440 and semver specs are incompatible due to how alpha/beta/rcs need to be written: PEP440 disallows dashes, semver requires them. Apart from that, they both allow for extended metadata
+suffixes (Local version identifiers in PEP440 terms).Not sure what's the right call here. It's a little bit of work changing build scripts etc, but work is coming anyway with the extra maintenance from non-complicance as semver has better support in non-Python tooling.
If we decide it's a good idea, we could do the switch for
v0.13.0.Not in a rush to make a decision, but I've been thinking about it for a while, and needed to write it down.