> On Oct 14, 2016, at 6:34 PM, Eloy Durán <eloy.de.en...@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 

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 



swift-evolution mailing list

Reply via email to