> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar <[email protected]> wrote: > >> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <[email protected]> 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? Or is there another >> rationale for having different defaults? > > I'll defer to this comment (linked from someone else earlier in the thread), > which happens to match up with my perspective: > https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537
I took that comment to be an explanation of why a library's lockfile/pinfile should not propagate to other packages that use it. That is clearly the case; such pin propagation would be nonsensical. My question was not about that, but about why libraries shouldn’t use a pinfile at all, even for their own _internal_ development. All the same “last know good build” concerns apply. The difference is that testing against that single last known good version set is sufficient for a top-level package, whereas a library should (1) ideally test against multiple valid dependency versions and (2) test often against new versions of its dependencies. I don’t see, however, that this implies that libraries should not have pinfiles at all — just that their release / CI process should not be limited to what’s pinned. Cheers, P _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
