> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution
> <email@example.com> wrote:
>> 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?
> 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.
The current idea wouldn't "disable it", it would discourage you from checking
it in for a library (it really comes down to you have to run two commands, not
one). I agree all the other things you outline are useful, and that not
checking it in doesn't magically solve the problem here.
> swift-evolution mailing list
swift-evolution mailing list