Need instructions on libraries that track another library.

[bf4]

If the yui-rails gem upgrades the yui3 library from version 3.10.3 to 3.13.0, but no yui-rails code has changed, I think the semantics should be

YUI_VERSION = '3.13.0'
VERSION =  "#{YUI_VERSION}.0.3.0"

where 0.3.0 is the 'yui-rails' version that follows semver independent of the YUI_VERSION.

[bessarabov]

Maybe it will help. On http://semver.org/ there is such info:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

[tbull]

I find this question rather justified. I don't have an answer to the question, I'm just thinking out loud.

If I understand your example correctly, yui-rails is a library (or any kind of software) that depends on a library called yiu, right? And the yiu version bumps from 3.10.3 to 3.13, while the yiu-rails version remains the same at 0.3. I presume there is a good reason why yiu-rails should use the newer version of the yui library, otherwise the question wouldn't make much sense. So we take it that the lib is updated while the software is not, and you find it important enough to recommend to use the updated lib with the software.

I see one main point of distinction: Do you distribute the dependency (yui lib) along with your software (yui-rails), or will the user himself take care of obtaining the dependency?

If you deliver the lib with your software, a lib update will effectively facilitate a bug fix or non-breaking change. In that case, the FAQ answer as cited by @bessarabov applies. Bump at least the patch version and make a new release.

The more common case, however, will be that of a package managment system on the user's machine taking care of fetching, installing and updating dependencies. There are again two cases to distinguish. One is where the library code is dynamically linked at runtime. This also applies to software and libraries written in a scripting langauge, such as Ruby. The package manager would notice the update of the library by the new version number, will update the library installation, and the newer lib will then automatically be used the next time the software is launched. So nothing needs to be done here.

The other case is where some compilation and static linking needs to be performed. This requires the updated library to be installed, and then the dependent software to be recompiled. The package manager would need a hint that the dependent software needs to be rebuilt. This is indeed a quite common scenario. So common, that for example the FreeBSD guys provided a facility in their 3rd party software management system called the "ports collection" to do exactly that. They maintain an own notion of port version numbers, which usually equals the version number assigned by the software vendor (0.3.0 in the above example), amended by some markers, one of which is that hint that a dependency has updated while the actual software has not. They call it the "port revision". It is another counter that is attached to the vendor version number with an underscore.

http://www.freebsd.org/doc/en/books/porters-handbook/makefile-naming.html

In our example that would lead to the version number 0.3.0_1. Note that the exact version of the dependency (3.13) is not included in the version number. That is not necessary. The hint, that there is an updated dependency is sufficient. The required version of the dependency has to be communicated by other means, anyway. Usually you would just link against the newest stable version.

Semver does not provide for this use case. We should think about if it should. For the time being, you can just re-release the exact same code with a newer patch number.

In the case of npm packages for the node runtime, each software package includes a file called package.json which details the dependencies with their required versions.

https://npmjs.org/doc/json.html#dependencies

In that case, the dependency specification is in fact part of the package, and bumping the patch number is more than justified, it's the right thing to do.

[bf4]

Interesting, so you would have the patch version include a reference to the tracked library version?

Yes, yui-rails includes javascript that I update periodically with yui releases. Otherwise, I haven't changed the library in a bit. So, the last few updates have just been updating the included library.

[tomByrer]

Including required libs in the distribution is becoming more common. I hope firm(er) guidance is released soon.

[bf4]

pinging @mojombo just in case you hadn't seen this issue and wanted to weigh in

[jwdonahue]

@bf4

Have you any further questions in regard to this issue? Any proposed changes to the SemVer spec? If not, then please close this issue at your earliest possible convenience.

[bf4]

@jwdonahue The issue doesn't appear to be resolved, IMHO. I'll let a maintainer weigh in.

I do think that since posting this, the direction has been to directly track major version numbers, or some such.

[jwdonahue]

@bf4, neither @mojombo or @haacked have weighed-in over the past four years, but you might get lucky.

Looking closer at your proposal, I don't believe it conforms to SemVer, as you seem to be building a compound version number that looks something like "3.13.0.0.3.0". Did I read that correctly?

[jwdonahue]

@bf4, your problem is all about transitive dependencies yes? A depends on B, B gets a version bump, what should happen to A? Is that correct?

[bf4]

@jwdonahue yes, specifically in the case where A is a kind of domain-specific-adapter for B. So, if I want to add B to my app, I use A, which bundles B. This is more common now than when I first asked the question. e.g. https://github.com/jruby/activerecord-jdbc-adapter#activerecord-jdbc-adapter now tracks Rails 5.0.x as 50.x

[jwdonahue]

@bf4, how transitive dependencies are tracked is a matter for tooling, not semver. Semver provides a standard means for labeling nodes in a dependency graph, not how to mange the entire graph. Unless you intend to issue PR related to this thread, please close it at your earliest possible convenience.

[bf4]

Sounds like that would be the pr

…

On Sun, Oct 7, 2018, 9:52 PM Joseph Donahue ***@***.***> wrote: @bf4 <https://github.com/bf4>, how transient dependencies are tracked is a matter for tooling, not semver. Semver provides a standard means for labeling nodes in a dependency graph, not how to mange the entire graph. Unless you intend to issue PR related to this thread, please close it at your earliest possible convenience. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIuQmRcnk2Y9FeF-Hvq_YEPDujXCStwks5uir3agaJpZM4BPW1V> .

[jwdonahue]

The list of things the spec is not intended to cover would be too long for publication.

[bf4]

Closing as intentionally 'undefined' behavior