dub: should we make it the de jure package manager for D?

[Bruno Medeiros]

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