On Friday, 3 August 2018 at 19:41:32 UTC, Bastiaan Veelo wrote:
But if you commit it, and a compiler deprecation causes a dependency in that pinned version to fail to compile, then your app won't compile either, even though your code itself does not suffer from the deprecation and even though a newer release of the dependency is available that solves the deprecations. This means that, if your app is on code.dlang.org, people won't be able to dub fetch && dub run.
This is also true if the dependency gets a major version bump and then gets updated for a breaking compiler change.
If the dependency range is broad enough, you can `dub upgrade && dub run`.
What advantages does committing dub.selections.json have that outweigh this disadvantage?
Dependencies don't always follow semantic versioning. For instance, a binding for a C library that is actively developed might reasonably follow the bound library's versioning. Or the maintainer might make a mistake and commit a breaking change without bumping to a new major version.
This is why my top-level projects these days have specific versions of dependencies rather than the more commonly used ranges. I'm only going to test against those specific versions, so why should I claim that my application can use future versions?
It would be OK if dub.selections.json would also pin the compiler version and there were a standard way to select that version (like dvm, but without its shortcomings).
That would be good. If I were less lazy, I could add that to dub. It already manages packages; the compiler is just a slightly different dependency.
