> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution > <swift-evolution@swift.org> 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? >> >> 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.
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. - Daniel > > Cheers, > > Paul > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIGaQ&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=teZCCTj9bCvNJ4SX_xKQ4SOVlaMWK9IXMlx_HMapKUU&m=wl9y8ecLDwSW83LjsOje4Jz1_TjqamVYnv-lTnVooiI&s=ICIfe-G4A6ZgJyiYYtMnHpq6JKQpHA5nhxc8nG4GxhY&e= > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
