Adding git commit hash / source version id to the version number #435

New Issue

GiteaMirror · 2026-02-17T12:05:00-06:00

GiteaMirror commented

2026-02-17 12:05:00 -06:00

Originally created by @matepek on GitHub (Sep 18, 2020).

Hello,
I'm just wondering what are the cons and pros of adding a git commit hash (or some kind of version control identifier) as part of the version. For first it seems useful to me.

<valid semver> ::= <version core>
                 ...
                 | <version core> "-" <pre-release> "+" <build> "#" <source-version-id>

Originally created by @matepek on GitHub (Sep 18, 2020). Hello, I'm just wondering what are the cons and pros of adding a git commit hash (or some kind of version control identifier) as part of the version. For first it seems useful to me. ``` <valid semver> ::= <version core> ... | <version core> "-" <pre-release> "+" <build> "#" <source-version-id> ```

GiteaMirror added the consensus seeking label 2026-02-17 12:05:00 -06:00

GiteaMirror commented

2026-02-17 12:05:01 -06:00

@ghost commented on GitHub (Oct 25, 2020):

If you could concatenate the hash the be the same size as <build>, then maybe? Something like this:

<valid semver> ::= <version core>
                 ...
                 | <version core> "-" <pre-release> "+" <build> 
                 | <version core> "-" <pre-release> "#" <source-version-id>

@ghost commented on GitHub (Oct 25, 2020): If you could concatenate the hash the be the same size as `<build>`, then maybe? Something like this: ``` <valid semver> ::= <version core> ... | <version core> "-" <pre-release> "+" <build> | <version core> "-" <pre-release> "#" <source-version-id> ```

GiteaMirror commented

2026-02-17 12:05:02 -06:00

@matepek commented on GitHub (Oct 25, 2020):

Why is the "same size" a requirement?

@matepek commented on GitHub (Oct 25, 2020): Why is the "same size" a requirement?

GiteaMirror commented

2026-02-17 12:05:03 -06:00

@ghost commented on GitHub (Oct 25, 2020):

Thinking back, I guess it doesn't need to be. There are no size requirements AFAICT, aside from this recommendation:

Does SemVer have a size limit on the version string?
No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string.

The original <version core> "-" <pre-release> "+" <build> "#" <source-version-id> is too long in my opinion.

@ghost commented on GitHub (Oct 25, 2020): Thinking back, I guess it doesn't need to be. There are no size requirements AFAICT, aside from this recommendation: > Does SemVer have a size limit on the version string? No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string. The original `<version core> "-" <pre-release> "+" <build> "#" <source-version-id>` is too long in my opinion.

GiteaMirror commented

2026-02-17 12:05:03 -06:00

@matepek commented on GitHub (Oct 25, 2020):

Technically should be redundant. But seems so convenient having it.
Build number can be essential too. The "good judgment" is a guide for the users (like me) but the standard could allow it. ^^

@matepek commented on GitHub (Oct 25, 2020): Technically <source-version-id> should be redundant. But seems so convenient having it. Build number can be essential too. The "good judgment" is a guide for the users (like me) but the standard could allow it. ^^

GiteaMirror commented

2026-02-17 12:05:04 -06:00

@ghost commented on GitHub (Oct 25, 2020):

The build metadata already allows for commit hashes to be used (along with the build number if you wish) as long as the hash is alphanumeric.

@ghost commented on GitHub (Oct 25, 2020): The build metadata already allows for commit hashes to be used (along with the build number if you wish) as long as the hash is alphanumeric.

GiteaMirror commented

2026-02-17 12:05:05 -06:00

@Nixinova commented on GitHub (Jan 12, 2021):

Just include the git hash as part of the metadata string. Use a double hyphen or something instead of a hash sign and that grammar works.

@Nixinova commented on GitHub (Jan 12, 2021): Just include the git hash as part of the metadata string. Use a double hyphen or something instead of a hash sign and that grammar works.

GiteaMirror commented

2026-02-17 12:05:05 -06:00

@jwdonahue commented on GitHub (Sep 7, 2021):

The meta tag is where we traditionally put content hashes. The use of the # character could cause problems in some systems, where the version string is encoded in a URL, but we already have to work around the + character on that score. Why add another one? If we were to add tag types to SemVer, a VersionMeta tag would top my priority list. Then you could independently define the format your prerelease and buildmeta tags as well.

@jwdonahue commented on GitHub (Sep 7, 2021): The meta tag is where we traditionally put content hashes. The use of the `#` character could cause problems in some systems, where the version string is encoded in a URL, but we already have to work around the `+` character on that score. Why add another one? If we were to add tag types to SemVer, a [VersionMeta tag](https://versionmeta.org/) would top my priority list. Then you could independently define the format your prerelease and buildmeta tags as well.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#435