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

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.

Start at the semver.NewVersion entry point and trace the parsing logic for pre-release identifiers, especially the handling of a leading zero followed by a letter. Add a regression test for 0.0.1-0f9a5fdef.38 and verify that it parses without error or mangling while the existing pre-release cases remain valid.