[swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Daniel Duan]

Daniel Duan
Sent from my iPhone

On Nov 2, 2016, at 11:17 PM, Martin Waitz <tali at admingilde.org> wrote:

>> Am 03.11.2016 um 03:22 schrieb Daniel Duan <daniel at duan.org>:
>> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>>> What is your evaluation of the proposal?
>>> 
>>> +1 for using reproducible versions of dependencies
>>> -1 for the actual proposal
>>> 
>>> My problem with this proposal is that it tries to please everybody by introducing options everywhere.
>>> …
>>> We should just drop all these problems and design a system which works for all use-cases
>>> without having to manually pin dependencies.
>> 
>> The second half of the sentence contradicts with the first half. What if I need to only pin some of the dependencies, have have the rest update automatically?
> 
> No contradiction:
> Storing versions of all dependencies and having reproducible builds is independent from updating dependencies.
Ok, agreed.

> What you need is some automatic (e.g. driven by CI) system to update your dependencies.
When you say "update", I assume you mean the action of increasing version numbers of certain dependency? I don't see how CI is going to help with that.

> When performing an update is the right time to select what you want to update.
> Then you can also test the new set and document that you chose to update them.
What kind of "documenting" are we talking about? I thought the .pins is a place record precise version of the dependency we need. 

> Updates should always be explicit actions, not happening randomly at checkout time.
I agree strongly that update should be explicit. Which is why running a pin command for a specific dependency *after* it's been tested is better. I'm guessing you are saying this because I mentioned dependencies that aren't pinned. If you have worked with internal frameworks that gets changed frequently with a CI running unit tests and integration tests, you'd realize that pinning it is a waste of your teams time. But there's nothing to prevent you from doing it with this proposal.
> 
> — Martin

It comes down to this: if you want automatic pinning, your build script should run the pin commands whenever you deem necessary.

The converse isn't true: if you force everyone to automatically pin, then there's no way to opt-out. Whether that's desirable is not up to anyone to decide.