Comment by nathanaldensr | Hacker News Reader

Comment by nathanaldensr | Hacker News Reader

Interesting to see this topic coming up. I just recently complained to Microsoft about how Azure Artifacts' "Universal Packages"[1] only supports strict Semantic Versioning with no extras (no additional version number components past patch and no commit hash). This is problematic because there are still several versioning schemes that use four version components, most notably Windows binaries. I was really interested in using Universal Packages to store application binaries as part of a set of new CI pipelines I'm architecting; unfortunately, I have to resort to NuGet, which still supports <major>.<minor>.<patch>.<buildid>+commithash syntax.

I realized the issue was with Semantic Versioning itself. The spec should be changed to mention that any number of additional dotted version components are allowed after <major>.<minor>.<patch> but that they have no semantic meaning. This would help address legacy versioning concerns like mine while not being too prescriptive.

Only having three version components is additionally problematic because there is no place for CI build IDs in the version. Imagine I'm working in a bug-fix branch called 1.5.4. I might have several commits that all trigger CI pipelines. I don't want to increment the patch component until I actually merge the bug fix into master, but I still want my CI system to generate unique version numbers per build. There currently doesn't seem to be a way to do that without being forced to use pre-release identifiers (e.g., 1.5.4-beta.1, -beta.2, etc.), which unnecessarily complicates the CI pipeline.

[1]: https://docs.microsoft.com/en-us/azure/devops/artifacts/quic...

Timely for me as well. Another reason for adding an additional version number component is this: I use an open source library that I need to fork. Since the library uses the `patch` number component, it's hard to release forked versions to NPM without having conflicting patch numbers.

For example, if the library is at `0.15.4` I don't want to release my updates as `0.15.5`, `0.15.6` etc. because when the main library updates to `0.15.5` we have conflict/confusion. Instead, I'd like to `0.15.4.1` to indicate my `.1` update to `0.15.4`. When they update to `0.15.5` I can merge and release a version at `0.15.5.1`

Exactly.

In my case, I'm using Azure Pipelines' "build ID" concept as a globally-unique integer. Given any fourth version component (e.g., the 125 in 1.5.4.125) I can identify the exact unique build that generated that artifact. No two builds across all artifacts will ever share the same build ID. It's a great way of finding the build of any artifact even if all I have is a version number.

SemVer calls it a pre-release identifier but you can in fact put anything you want in there that matches the syntactic rules, so you could just use your build id as a pre-release identifier. Or as the build id field, if you're not already using that.

The issue with doing it that way is package managers like NuGet can "hide" pre-releases--they treat them as different fundamental types of packages. In my case, I don't want that designation. I realize I could use pre-release identifiers but I'd rather have the artifact versioned "first-class," so to speak.

I would suggest putting it in the "build metadata" section then. If you're already putting a commit hash there, you can use the hyphen to separate it, like. 1.5.4+build123-b5bb9d80

The standard separator for build metadata fields is a period, since the section is ignored for version comparison it doesn’t really matter, but the spec does specify it (and some tools may display separate fields differently).

Oh you're right. I glanced at the spec and saw that it defined build metadata as [0-9A-Za-z-] but didn't realize that it was actually defining this as a dot-separated series of components where each component was [0-9A-Za-z-].

Reply on news.ycombinator.com