1

I cannot find a way to link against the “SwiftPM” package with Swift 4.2:

  • The latest semantic version is 0.2.1, which crashes when loading a manifest because it looks in the JSON for “isTest”.
  • The swift-4.2-RELEASE tag works perfectly. The problem is that it is a “branch” dependency, which means the client package cannot release stable versions.

It looks like all it needs is someone with enough authority to tag a 0.3.0 release based on the state of swift-4.2-RELEASE.

Or is there something I’m missing?

@Aciid, @ddunbar

2

We can tag a new version but I wonder if we should follow SwiftSyntax's versioning scheme where they attach the Swift version in the semver tag. So instead of 0.3.0, it'd be 0.40200.0 for the Swift 4.2 release. The advantage is that it is easy to identify which compiler release a tag is attached to. What do others think?

/cc @ddunbar @rballard

1 Like
3

I wondered that too. I do find the 0.40200.0 system more intuitive.

4

Although I understand the convenience, I don't care for abusing the semver system. I think if we believe semver is useful, we should ourselves eat the pill of having versions which don't correlate (living on the same pain we are expecting others to feel). If we don't do this, we may avoid seeing pain points that we are expecting others to endure, or opportunities to improve them with tooling.

5

I agree with you but we're not really fully using semver yet due to lack of a stable API. The 0.x.x scheme signifies that each version can break the API. But yeah, we should definitely switch to proper semver practices once we have the first 1.0.0 release.

2 Likes
6

Embedding the marketing version in semver just because you can while in the 0.x version range doesn’t sound like a good idea to me. If people get used to having that, we can’t ever tag a stable API without breaking the existing convention for how we express marking version. These things -- API stability and how one communicates marketing version -- should be decoupled.

I do think we should consider whether to add some good convention / affordance for adding marketing version info to Swift packages, but that might not be terribly useful without a future package index.

7

Sounds good :+1:. I'll create a new 0.3.0 tag from the swift-4.2-branch. It is a few commits ahead of the swift-4.2-RELEASE tag but those commits contain a couple of very important bug fixes.

Edit: This is done Release 0.3.0: Merge pull request #1768 from ahoppen/show-bin-path-4.2 · apple/swift-package-manager · GitHub

8

Thanks.

9

Even if we don't maintain a stable API, I think it would be good if we "tried" to use the semver as we evolve the API. For example, putting in place practices for annotating PRs that change the API. NIO appears to have an excellent practice in this regard.

10

Did you update your manifest for the Swift version target you're on?

11

I don’t understand your question. To whom is it directed? To what manifest does it refer?

In case there was some confusion, this thread is old and the issue which prompted it has long been resolved. The following builds and links fine with Swift 4.2(.1):

// ...
dependencies: [
    .package(
        url: "https://github.com/apple/swift-package-manager",
        .exact(Version(0, 3, 0)))
]
// ...
12

I don’t see any new release tag in the SwiftPM package to go along with Swift 5.0.

Is 0.3.0 supposed to still work? It is not crashing, but I’m getting some weird test results in my client code. For instance, the loaded package graphs somehow contain no packages.

@Aciid

13

I haven't tested but I won't be surprised if 0.3.0 is not working anymore with the latest manifest format. Currently, there is no official process for making new (semver) tags and I only do it when someone asks. I'll make a tag that matches Swift 5 release tomorrow. Meanwhile, maybe you can depend on the swift-5.0-branch?

14

I just tried depending on swift-5.0-RELEASE, but it resulted in build failures in llvmSupport such as undefined symbol: _del_curterm. (That was with the generated Xcode project.) I’ll try a raw package manager build too.

15

The package manager seems to be capable of building swift-5.0-RELEASE, but Xcode failed to build llvmSupport again on a clean build. This is the error message:

Undefined symbols for architecture x86_64:
  "_del_curterm", referenced from:
      terminalHasColors(int) in Process.o
  "_set_curterm", referenced from:
      terminalHasColors(int) in Process.o
  "_setupterm", referenced from:
      terminalHasColors(int) in Process.o
  "_tigetnum", referenced from:
      terminalHasColors(int) in Process.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
16

swift-5.0-branch behaves exactly the same as swift-5.0-RELEASE.

17

@Aciid (not sure if you get notified without being named)

A new semver won’t be particularly helpful until the errors above are dealt with.

I also see no semver tags in swift-llbuild so it probably needs a valid version first in order for SwiftPM to reference it.

18

I get notified for all things in the Package Manager category :slight_smile:

You need to generate the Xcode project with this xcconfig file: https://github.com/apple/swift-package-manager/blob/master/Examples/package-info/config.xcconfig

Also see:
https://github.com/apple/swift-package-manager/blob/master/Examples/package-info/Makefile#L23

19

Won’t that requirement cascade to client packages?

Is there a way to use the new target specific build settings to accomplish it? This makes it sound like the answer is probably no:

Products that contain a target which uses an unsafe flag will be ineligible to act as a dependency for other packages.

20

It is possible to use the new target specific build settings. We just need to update the llbuild manifest.