semver fails to accept pre-release starting with '0f' (e.g. 0.0.1-0f9a5fdef.38) – valid SemVer rejected

[iamshreeram]

Summary

Version strings with a pre-release starting with 0f (e.g. 0.0.1-0f9a5fdef.38) are rejected as invalid, even though they are valid according to SemVer 2.0.0, section 9. This causes downstream tools (such as Helm) to fail when using such versions.

To Reproduce

• Parse or validate a version string such as:
  0.0.1-0f9a5fdef.38
• Observe:
  • Error is thrown, or version string is mangled (extra zero/dot may be added, e.g. 0.0.0.1-4e43d1a30.5f9a5fdef.38)
• Other pre-releases, such as 0.0.1-485ca4b.38, 0.0.1-07c062a.38, or 0.0.1-b95cec4ab.38 parse successfully.

Example

import "github.com/Masterminds/semver/v3"

v, err := semver.NewVersion("0.0.1-0f9a5fdef.38")
fmt.Println(v, err) // err is not nil

Expected Behavior

• Pre-release identifiers beginning with 0f (zero + letter) should be accepted per SemVer spec.
• No error should be thrown for valid semver strings.

Actual Behavior

• Error thrown, or version string is mangled before parsing.
• Downstream projects (e.g. Helm) are unable to use valid version constraints with pre-releases starting with 0f.

Additional Context

• Related Helm bug: helm/helm#31026
• Affects any tool depending on this semver library for constraint parsing/validation.

Potential Fix

• Audit the parsing logic for pre-release identifiers, especially for cases where a pre-release starts with a zero followed by a letter.
• Add tests for cases like 0.0.1-0f9a5fdef.38.

[mattfarina]

This is a bug. Great catch.

[mattfarina]

I've not been able to reproduce this in Helm or with this package. I added more tests for this in bf01c61. No changes were needed for things to pass as expected.

Can you please provide more detail to replicate?