What the version should be if only dependencies were updated?

[nurupo]

Say you have a GUI application that links to OpenSSL and follows SemVer. A year has passed since its last release. There were no changes to the software since then. However, since then there were new vulnerabilities found and fixed in OpenSSL, so it makes sense to release a new build of the same version of the GUI application with the only change being the newer OpenSSL version bundled. This is especially true for Windows, where applications ship their own deps. What version should such release have? We can't re-release under the same version, overwriting the previous version's builds, as updating OpenSSL might have unintentionally introduced new behavior, and it also makes sense to keep the previous builds just for the reproduciblity sake, we don't want to overwrite them. We could release as the same version but +1 build metadata, e.g. if the 1 year old version was v1.16.3, the new one would be v1.16.3+1. But SemVer says that:

two versions that differ only in the build metadata, have the same precedence

when we clearly want users (or some sort of Windows package manager software following SemVer) to prefer the newer build, we don't want them to treat the old and the new builds with the same precedence.

[jjlharrison]

In my organisation we would increment the patch version in this instance as we consider bugs (such as security vulnerabilities) inherited from dependencies to be bugs in the application itself.

[jwdonahue]

I think It's definitely a patch level change in your scenario. Buildmeta is the wrong place to encode such changes, as it does not factor into the sort order and would therefore rarely be picked up by humans or automation.

Now transitive dependencies can break systems where side-by-side installation/execution is not possible. So if you can't isolate your version of OpenSSL from other applications that also use OpenSSL and OpenSSL ships a breaking change that you incorporate into your product, then you would likely have to bump your major version. But the later really depends on the tool chains and run-time environment. If the tools/environment prevent a user from unintentionally breaking all of their other OpenSSL dependent apps by taking your update, then as the spec is currently worded, you still have a patch-level bump.

[jwdonahue]

@nurupo, this question has been asked and answered in the past, with many nuanced scenarios, both here and on the SemanticVersioning tag at StackOverflow. Run a search for "transitive dependency" or "transitive dependencies" (actually, just "transitive" would probably be better).

Unless you have further questions, please close this thread at your earliest possible convenience.

[jwdonahue]

Similar questions: #560, #534, #526, #522, #341, #337, #213.

[nurupo]

Thanks, will read them.

I see that most of them talk about API and ABI changes, when in my case it's just a desktop GUI application, there is no API or ABI, it's supposed to be used directly by a human.

There is also the part that we are mixing two concepts together: code version and build version. It just happened that previously each software release had a corresponding Windows build made for it that used code's version as its name. But now we want to update our Windows builds with a new OpenSSL version, but we don't modify any code in our GUI application, it's literally identical, so there is no version change of the code, yet we want the binaries to have a version bump, which is what creates this confusion of how it should be handled. If we follow the advice of @jjlharrison and @jwdonahue, we end up releasing a build that is named v1.16.4 which, however, uses v1.16.3 code version, and in our git repository there is no v1.16.4 tag, there is only v1.16.3. So our code and build versions decoupled. So what happens next, when we modify our code and release v1.16.4 version of it, should we call the corresponding build v1.16.5 now? Or should have we made a v1.16.4 code release that is identical to v1.16.3 back when we were creating v1.16.4 build? But nothing has hanged in our code, and users on Linux, who get OpenSSL updates as part of their distro updates, would have no reason to update to v1.16.4, it would be a pointless update for them, it's identical to v1.16.3.

[darianmiller]

If your build dependency info is not in your repository you could create a new text file to signify the OpenSSL version being used in the build. In your example, if nothing changes except the OpenSSL version at least that single dependency info file can be updated and a new 1.16.4 tag created. I would close this issue.

[jwdonahue]

@nurupo

Tagging the repo with version numbers is not necessary and in some cases undesirable. In the absence of other reference sources, it can be convenient for developers to go back and find the commit that produced a particular package, but the practice doesn't scale well and the tags are not immutable. It's better to encode the repo hash into the build-meta tag of the version string if your package tooling doesn't strip it off.