On 08/10/2013 13:38, Jacob Carlborg wrote:
On 2013-10-08 12:51, Bruno Medeiros wrote:
From what I understand, for dependency graph locking to work at all,
then each package (as stored in the central package repository) would
have to specify its full dependency graph in the package specification.
So the foo package would have to specify not only the bar dependency,
but also xyz=0.0.1 as a dependency. Isn't that how it would work?
No, now necessarily. Using Bundler it works like this:
* You have your Gemfile, corresponds to package.json in dub
* You run "bundle install"
* When you do that it will create a new file, Gemfile.lock. This file
contains the complete dependency graph of what it just installed.
* Running "bundle install" when Gemfile.lock exist, it will read
Gemfile.lock instead of Gemfile
Rigth, but then you would need to share the .lock file to the other
machine you want to install/compile "foo" in. The repository alone would
not be enough for that.
Rather, I think dub should adopt Semantic Versioning as part of its
recommended practices for package versioning:
http://semver.org/spec/v2.0.0.html
In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
upper bound on the version is required, to allow breaking changes in xyz.
Semantic versioning helps, but it won't solve the problem. I wouldn't
trust that a library actually follows the semantic versioning scheme.
It's quite easy to accidentally add new API without incrementing the
middle number. Or break the API.
Hum that is true. Especially without a tool that can verify API
compatibility.
--
Bruno Medeiros - Software Engineer
