`GitDescribeFormatter` produces invalid version strings for commit hashes starting with 0 and containing only numbers

[nitwhiz]

My version is called 2.13.0-dev.0350536 and the Shivas\VersioningBundle\Provider\VersionProvider throws a RuntimeException because Version::fromString throws an InvalidVersionString exception.

Origin of the exception: vendor/shivas/versioning-bundle/src/Service/VersionManager.php:114

0350536 are the first digits of the commit-hash this version originates from.

I know about the regex, see my tests here: https://regex101.com/r/UW2tok/2 but I don't understand what's going on. It's like the hash-prefix is not "hexy" enough.

• Library Version: 4.0.0
• PHP Version: 7.4.30

[dontub]

The regex in https://github.com/nikolaposa/version/blob/26eaae68350c52989e05e8e20326e0a66ac16068/src/Version.php#L18 says that the number in the pre release part can be a single 0, but not a number starting with 0: 0|[1-9]\d*. This is in conformance with the semantic version spec https://semver.org/#spec-item-9:

Numeric identifiers MUST NOT include leading zeroes.

As the regex comes from https://github.com/nikolaposa/version and is not in this bundle it's nothing this bundle can do about, anyway.

[nitwhiz]

Ah yeah, you're right.

But given this, the GitDescribeFormatter (the source of my 2.13.0-dev.0350536) produces incorrect versions if the commit-hash consists of only numbers beginning with a 0. (Which is rare, but it may happen and shouldn't be a problem) - It should be 2.13.0-dev.g0350536 then.

It cuts the g at the beginning of git-described versions and thus instead of v2.13.0-1-g0350536 we get 2.13.0-dev.0350536. With the g, it would be a correct pre-release.

We're dealing with commit-hashes here, they aren't "numbers" by definition, they're strings consisting of [0-9a-fA-F].

[shivas]

And just my 2 rusty cents: Commit hashes are precise that - a number, a big one. And [0-9a-fA-F] is just a character set for HEX encoded bytes :) And yes, hex encoding is mainly used for consistent-length string-like representation

[nitwhiz]

I think you misunderstand me.

The current implementation breaks randomly when calling $manager->getVersion(), if the version is a result from the GitRepositoryProvider.

randomly = The current version is untagged and has a commit hash that is starting with a 0 and consists of only numbers.

This means the library does not support some of the version strings it created itself. Which brings me back to the quintessence of all of this and maybe a better issue title: The GitDescribeFormatter produces invalid version strings in special cases.

Essentially, because it cuts the g off the version git-describe produces. With the g, it would be a valid version in all cases.

Or am I getting something wrong here?

My workflow is the following:

1. $manager->getVersion() -> 2.13.0-dev.0350536
2. This value is written to VERISON file
3. Deployment to remote server
4. On remote server: Version is parsed from VERSION file
5. -> InvalidVersionString exception

[dontub]

Now I got it. Thanks for the explanation. Keeping the g would be the best solution. I'm just wondering, if it could be a problem for anybody if there suddenly appears a g. But probably not.

[nitwhiz]

I don't think so, either.

But, I suggest the following format: 2.13.0-dev+0350536. This way, we're specifying <commit-sha> as build-information and dev as pre-release. See Section 10.