> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <cantr...@pobox.com> wrote:
> Sorry for the late arrival to this thread. Comments below…
>> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev
>> <swift-build-...@swift.org> wrote:
>> What this proposal about is in one sense being able to export and share
>> those pins.
> This is a crucial and clarifying insight. It should be in the proposal! Near
> the top.
Good idea, will incorporate it.
>> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default.
> Indeed. Pins should be only be about sharing specific versions within a
> development team — not with client packages / apps. What’s pinned in Vegas
> stays in Vegas. Publishing pins to other projects would be nonsensical.
>> 5. Given that many people agree there are two workflows (we ourselves had
>> talked about this a lot when writing the proposal, but didn't put it in), we
>> felt it makes sense to consider adding that as an explicit declaration
>> @Eloy, @Orta: Suppose we had a semantic notion of which packages were
>> intended to be "top-level" versus used as a dependency, and we chose our
>> defaults accordingly (in this case, we would orient workflows towards
>> pinning by default in the top-level case, in the used as a dependency case
>> we would orient away from it, e.g. warning you if you checked it in). What
>> would you think of such a design?
> 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:
> Cheers, P
swift-evolution mailing list