<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=""><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">On Sep 6, 2016, at 1:15 PM, The CB4 via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">Working on Swift 3 migration, a lot of github projects have an non-versioned swift3 branch. I've had to fork projects and create my own version tags... A lot of unnecessary work.</div></div></div></div></blockquote><br class=""></div><div class="">A thousand times this.</div><div class=""><br class=""></div><div class="">Clearly using carefully versioned releases is preferable, but the lack of branch support in SwiftPM is a point of pain.</div><div class=""><br class=""></div><div dir="auto" class="">My several cents on Daniel’s questions:</div><div dir="auto" class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Sep 6, 2016, at 12:06, Daniel Dunbar via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""></div></div></blockquote></div></div></blockquote><div class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class="">One of the things that a complete proposal for adding this needs is a precise definition for the workflow and exploration about the impact on other features. Some of my questions are:</div><div class=""><br class=""></div><div class="">1. When will those commits be resolved and packages updated? For example, we might find it useful for `swift build` to automatically fetch packages and prompt when new versions are available when using tagged dependencies -- is that behavior appropriate when tracking a branch?</div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">If possible, the semantics should be parallel to those of open-ended specifiers like “majorVersion: 3”. Whatever updating & pinning mechanisms apply to one should apply to the other.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">2. How do we manage the presence of these attributes w.r.t. producing reliable package graphs. For example, should this be allowed in all circumstances, or should it only be allowed when accessing a package via an "untagged" path? If I depend on B, and B updates and pushes a tag to start referencing a branch, do I see an error, or a warning, to let me know my product is no longer being built from tagged repositories?</div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Emit a warning.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">If B has pinned a version, use that version. If this creates a conflict between transitive dependencies pinned to different commits:</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">• if one commit is the ancestor of the other, emit a warning;</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">• otherwise, emit an error.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I give these rules thinking of the common case: several packages doing new development in tandem — as in CB4’s Swift 3 example.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Where there are branches running around in the dependency graph, developers should expect some instability and unexpected breakage; however, it’s crucial to be able to detect that breakage without have to cut new versions.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3. We anticipate needing an explicit workflow for development against an untagged group of packages (we've been colloquially calling this "master"-style development). If we had that feature, which let you just use a bunch of packages in whatever state they were in on the local filesystem, would that change how you felt about wanting this in the `Package.swift` manifest?</div></div></blockquote><br class=""></div></div><div dir="auto" class="">No.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Again, this should support multiple packages developing new features in tandem — packages that may have different owners.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Cheers,</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Paul</div><div dir="auto" class=""><br class=""></div></div></body></html>