> On Oct 14, 2016, at 8:00 PM, Paul Cantrell <cantr...@pobox.com> wrote:
>>> 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:
>> 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.

A few comments down, Yehuda even provides an example of him doing just that 
with Bundler:


But in this case you actually want to maintain *many* lock files, and so it 
seems fine to require a bit of extra work (passing some flags) to do this. 
Drifting tests are the better default here. It makes library CI into an 
alpha-tester, empowering binaries to be more confident in upgrading frequently.

> Cheers, P
swift-evolution mailing list

Reply via email to