[swift-build-dev] [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Martin Waitz]

Hi Boris,

> Am 31.01.2017 um 03:48 schrieb Rick Ballard <rballard at apple.com>:
> 
>> 
>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> OK, you are right, branches can be helpful to have in the manifest.
>> But I’m still confident that we must not put explicit version information into it.
>> They belongs into the `Package.pins` file.
>> That is enough to get reproducible builds.
> 
> By "explicit version information", do you mean that you shouldn't put a git revision hash in the manifest – only branches and version tags should be acceptable?

yes exactly.
BTW: the more I think about it, the more I like the possibility to specify a branch in the manifest.

> I'd agree that the revision-based initializer is a marginal feature; normally your package should depend on a version range or is tracking a branch. That said, we can imagine that you might wind up needing to peg your dependency to a specific revision that isn't a version tag, and not track a moving branch, so this seemed like a fairly harmless feature to add for that case. What is your objection about supporting that?
> 
> The decision about whether to put this information in your pins or in your manifest should be driven by whether it's something your package requires, or is just a workflow choice. If you just want to temporarily stick to a specific revision of your dependency for workflow reasons, pinning is the right way to do that. If, however, your package currently requires that revision, and isn't going to work properly without it, then the manifest is the right way to express that. You'd want that specification to stick even if someone did `swift package update --repin` to get newer pinned revisions.

Well, I guess your package will also work with all commits following your special one.
Then I’d be enough to specify the branch: your special dependency version is already specified in the pins file and `swift package update` will only update to newer revisions.

So why would you (temporarily) want to stick to a specific version?
Because it happens to be the only compatible one at that time.
So even that is a workflow thing and not a „this is the one and only“.
And if you really really need to choose a specific commit which is in the past, then you can always create a special branch just for it.

I really like to have a clear separation between manifest and the pins file.
Otherwise I fear that inexperienced maintainers hard-code their dependencies to a specific version by accident.
I've seen too strict version specifications too often already (e.g. on npm) ;-)

— Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170131/d958c305/attachment.html>