<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 30, 2017, at 11:43 PM, Martin Waitz <<a href="mailto:tali@admingilde.org" class="">tali@admingilde.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Boris,<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 31.01.2017 um 03:48 schrieb Rick Ballard <<a href="mailto:rballard@apple.com" class="">rballard@apple.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">OK, you are right, branches can be helpful to have in the manifest.</div><div class="">But I’m still confident that we must not put explicit version information into it.</div><div class="">They belongs into the `Package.pins` file.</div><div class="">That is enough to get reproducible builds.</div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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?</div></div></blockquote><div class=""><br class=""></div>yes exactly.</div><div class="">BTW: the more I think about it, the more I like the possibility to specify a branch in the manifest.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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?</div><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote><br class=""></div><div class="">Well, I guess your package will also work with all commits following your special one.</div><div class="">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.</div><div class=""><br class=""></div><div class="">So why would you (temporarily) want to stick to a specific version?</div><div class="">Because it happens to be the only compatible one at that time.</div><div class="">So even that is a workflow thing and not a „this is the one and only“.</div><div class="">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.</div><div class=""><br class=""></div><div class="">I really like to have a clear separation between manifest and the pins file.</div><div class="">Otherwise I fear that inexperienced maintainers hard-code their dependencies to a specific version by accident.</div><div class="">I've seen too strict version specifications too often already (e.g. on npm) ;-)</div></div></div></div></blockquote></div><br class=""><div class="">This is not for the case where a package will work with all commits on a branch after the designated one. If that's the case, indeed a branch should be specified instead. This is for the case where there is a specific commit that's needed, and it doesn't have a version tag, and it either isn't on a current branch or the branch has moved past it to something incompatible.</div><div class=""><br class=""></div><div class="">You can't necessarily create a special branch for such a commit because you may not have permissions to push new branches to the repositories of your dependencies.</div><div class=""><br class=""></div><div class="">One thing to note is that if a maintainer does use this feature inappropriately, their package will fail once they tag it for release. One of the behaviors specified by this proposal is that if a package is found via a version tag, then if that package specifies any further dependencies via branch or revision, that is an error. The rule is that any versioned tag needs to fully specify all other dependencies via versioned tags. So a novice user will find out pretty quickly that they can't rely on revision specifiers for their actual releases.</div><div class=""><br class=""></div><div class="">In the future we hope to add a command to SwiftPM to help you prepare your package for a tagged release. That process would check this for you, among other things, so you'd find out about this problem before you created the tag.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Rick</div><div class=""><br class=""></div></body></html>