Has there been any discussion on allowing direct specification of commits or branches for the Swift Package Manager on the list? Currently it only supports semantic versioning tags, which makes for a tricky development process for developers adding Swift 3 support to their packages.
For example, consider a Swift 2.2 library that is tagged with 0.2.0. If developer wants to support Swift 3, they have to either add Swift 3 support with #if swift directives which is difficult due to the large number of source changes in Swift 3 and then tag an maintain the new version in the normal way, or maintain a separate Swift 3 branch. Maintaining a separate branch is tricky because in order to use Swift PM you have to tag commits on the new branch. Would this new branch be tagged 0.3.0? What if there needs to be a new release under Swift 2.2? It’s also unfortunate because the developer has no way of letting other developers use the package without creating a release tag.
This difficultly would me drastically mitigated if Swift PM allowed the tracking of the latest commit on a branch, or the ability to specify a particular commit as a version.
I’m going to shamelessly bump this, because this is a pretty huge pain point for me, and I think others who are trying to build and test with Swift 3.
···
On May 14, 2016, at 3:12 PM, Tyler Fleming Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
Has there been any discussion on allowing direct specification of commits or branches for the Swift Package Manager on the list? Currently it only supports semantic versioning tags, which makes for a tricky development process for developers adding Swift 3 support to their packages.
For example, consider a Swift 2.2 library that is tagged with 0.2.0. If developer wants to support Swift 3, they have to either add Swift 3 support with if swift directives which is difficult due to the large number of source changes in Swift 3 and then tag an maintain the new version in the normal way, or maintain a separate Swift 3 branch. Maintaining a separate branch is tricky because in order to use Swift PM you have to tag commits on the new branch. Would this new branch be tagged 0.3.0? What if there needs to be a new release under Swift 2.2? It’s also unfortunate because the developer has no way of letting other developers use the package without creating a release tag.
This difficultly would me drastically mitigated if Swift PM allowed the tracking of the latest commit on a branch, or the ability to specify a particular commit as a version.
Daniel Dunbar is working on a version pinning proposal and it will solve
issues like this.
···
On Mon, May 23, 2016 at 1:54 PM, Tyler Fleming Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
I’m going to shamelessly bump this, because this is a pretty huge pain
point for me, and I think others who are trying to build and test with
Swift 3.
> On May 14, 2016, at 3:12 PM, Tyler Fleming Cloutier via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Has there been any discussion on allowing direct specification of
commits or branches for the Swift Package Manager on the list? Currently it
only supports semantic versioning tags, which makes for a tricky
development process for developers adding Swift 3 support to their packages.
>
> For example, consider a Swift 2.2 library that is tagged with 0.2.0. If
developer wants to support Swift 3, they have to either add Swift 3 support
with if swift directives which is difficult due to the large number of
source changes in Swift 3 and then tag an maintain the new version in the
normal way, or maintain a separate Swift 3 branch. Maintaining a separate
branch is tricky because in order to use Swift PM you have to tag commits
on the new branch. Would this new branch be tagged 0.3.0? What if there
needs to be a new release under Swift 2.2? It’s also unfortunate because
the developer has no way of letting other developers use the package
without creating a release tag.
>
> This difficultly would me drastically mitigated if Swift PM allowed the
tracking of the latest commit on a branch, or the ability to specify a
particular commit as a version.
>
> Tyler
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution