> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar <daniel_dun...@apple.com> wrote:
>> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <cantr...@pobox.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? 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:
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.
swift-evolution mailing list