[swift-build-dev] [swift-evolution] Proposal: Package Manager Version Pinning

[Paul Cantrell]

> On Oct 14, 2016, at 6:34 PM, Eloy Durán <eloy.de.enige at gmail.com> wrote:
> 
>> I’m puzzled. If a package’s pinning does not affect any other package that uses it, why should the defaults be different? A library will still suffer from all the “works for me” problems an app might.
>> 
>> Is the rationale that not pinning libraries encourages accidental testing of new versions of a library’s dependencies as they arrive?
> 
> Yep.

I’m skeptical of whether disabling pinning by default is the right answer. It seems … haphazard and incomplete, likely to confuse those who don’t understand this reasoning, and only incidentally helpful to those who do.

I’d prefer an approach that is more mindful, more intentional.

Emitting warnings when newer versions of packages are available would help address the same issue. This would also encourage apps to get security patches promptly.

A more ambitious approach might be to provide a utility that installs and tests various combinations of all the semantically allowed versions of a lib’s dependencies — at the very least, all the lowest and highest allowed versions. This would ignore any existing pinfile. Library devs would run this prior to release, and on a CI server if they have one.

This would have the advantage of catching incompatibilities with _past_ versions of libraries as well as _new_ ones. In particular, it would catch too-permissive version specifications, e.g. if your library asks for foolib 3.x but relies on a bugfix in 3.4.2, this approach would catch that problem.

That’s clearly a bigger, separate idea, not necessary to hash out right now. I mean it just to illustrate what better approaches might look like. I’m skeptical that simply disabling pinning does a good job of solving the intended problem, and don’t think it should weigh quite so heavily on the proposal at hand.

Cheers,

Paul