leading zeroes can fail to be coerced

[maxnbk]

There was an issue a long time ago with a feature merged for leading-zeroes support, even though it's not technically semver to do so (Though I think it's good to support): https://github.com/rbarrois/python-semanticversion/issues/89

However, it does not work in all situations.

Version.coerce("1.2.3") -> works fine Version.coerce("1.2.000") -> works fine, gets interpreted as 1.2.0 Version.coerce("1.2.3.000") -> works fine, gets interpreted as 1.2.3+000 Version.coerce("1.2.3-000") -> breaks

It's difficult to know if this could called a bug or a feature-request, as leading-zeros aren't semver compliant, but since the original request was a feature, and ostensibly extends support for leading-zeroes, I would probably call this a bug with that feature. I could be misinterpreting something, though. In any case, it would be appreciated if this could be further supported.

[rbarrois]

Thanks for the feedback!

I agree that .coerce() should not fail on that input; however, 000 does not match clause 9 of the spec: numeric identifiers in a pre-release version must not contain leading zeroes.

A good test value would be:

>>> Version.coerce("01.02.03-04.0a.000023.000bcd+05")
Version("1.2.3-4.0a.23.000bcd+05")

• The build metadata is untouched (leading zeroes are allowed);
• Numerical identifiers in the pre-release part have their leading zeroes stripped;
• Non-numerical identifiers in that pre-release part are untouched.

I guess the code should instead look like this:

if prerelease:
  clean_prerelease = ".".join([
    bit.lstrip("0") or "0" if bit.isdigit() else bit
    for bit in prerelease.split(".")
  ])
  version = "%s-%s" % (version, clean_prerelease)