3 ms·

Interesting to see this topic coming up. I just recently complained to Microsoft about how Azure Artifacts' "Universal Packages"[1] only supports strict Semanti

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/quickstarts/universal-packages?view=azure-devops&tabs=azuredevops https://docs.microsoft.com/en-us/azure/devops/artifacts/quic...

thesunny 8y ago
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`
- nathanaldensr 8y ago
  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.
eridius 8y ago
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.
- nathanaldensr 8y ago
  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.
  - eridius 8y ago
    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
    - Nemo157 8y ago
      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).
      - eridius 8y ago
        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-].

thesunny 8y ago

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`

nathanaldensr 8y ago
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.

eridius 8y ago

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.

nathanaldensr 8y ago
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.
- eridius 8y ago
  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
  - Nemo157 8y ago
    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).
    - eridius 8y ago
      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-].