[swift-build-dev] [swift-evolution] SPM support for branches and commits

[Paul Cantrell]

> On Sep 6, 2016, at 1:15 PM, The CB4 via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

A thousand times this.

Clearly using carefully versioned releases is preferable, but the lack of branch support in SwiftPM is a point of pain.

My several cents on Daniel’s questions:

> On Sep 6, 2016, at 12:06, Daniel Dunbar via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 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:
> 
> 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?

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.

> 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?

Emit a warning.

If B has pinned a version, use that version. If this creates a conflict between transitive dependencies pinned to different commits:

• if one commit is the ancestor of the other, emit a warning;

• otherwise, emit an error.

I give these rules thinking of the common case: several packages doing new development in tandem — as in CB4’s Swift 3 example.

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.

> 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?

No.

Again, this should support multiple packages developing new features in tandem — packages that may have different owners.

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160906/7f8f09b9/attachment.html>