SwiftPM must relax its versioning requirements for dependencies

i was originally going to bump the Confused by unsafe flags being disallowed in dependencies - #51 by Joakim_Hassila1 thread, but i figured this is a different enough issue to warrant its own thread.

as i’m sure most of us are aware, SPM prohibits any of the following in a package that can be consumed by another package:

  1. dependencies which need “unsafe” flags like -Xcc -mcx16
  2. dependencies that follow “non-standard” release patterns.

the first restriction has been discussed at length in the other thread. i want to talk about the second restriction, because i am currently trying to add a dependency to the swift-markdown package, which does not follow semantic versioning (it has its own toolchain-synchronized release process).

according to the swift package index, swift-markdown has not tagged a ‘semantic’ release since the package was founded, and that release is not a semantic version release (it is not prefixed with v), so it can’t be used with SPM anyway. this appears to be intentional, because the instructions in the package’s README tell us to pin it to the default branch head:

.package(url: "https://github.com/apple/swift-markdown.git", .branch("main")),

so we cannot say that depending on the default branch head is not using the package as intended. and this strikes me as strange, because this implies that packages like swift-markdown are banned from SPM by design.

swift-markdown is not some random package developed by a third-party. it is an official package that releases with and is part of the toolchain (via DocC). and i feel that, in lieu of alternatives to SPM, SPM must support dependencies on packages that are part of Apple’s “official” sector of the ecosystem.

does Apple intentionally ship tooling that is incompatible with its own ecosystem?

1 Like

Your main question is a good one, but regarding this side note:

What? Any leading v is ignored. It was permitted as a courtesy for compatibility with other package managers needing to point at the same repository. It is officially equivalent to the standard tag format without it. 0.1.0 is the recommended way to tag a release of a Swift package, and is used in most of the documentation examples. Where did you get the idea SwiftPM would reject it?


i remember depending on 0.1.0 did not resolve the last time i tried it, but i just tried it again, and while it is still unresolvable, it looks like this is not because of the missing v, it is because of the swift-cmark dependency:

.package(url: "https://github.com/apple/swift-markdown", .upToNextMinor(
    from: "0.1.0")),
error: Dependencies could not be resolved because root depends on 'swift-markdown' 0.1.0..<0.2.0.
'swift-markdown' >= 0.1.0 cannot be used because package 'swift-markdown' is required using a stable-version but 'swift-markdown' depends on an unstable-version package 'swift-cmark' and no versions of 'swift-markdown' match the requirement 0.1.1..<0.2.0.

the impact is the same though, it appears there are no (!!!) extant versions of swift-markdown that can be used in a versioned SPM package.

aside: for the moment i am actually consuming your github fork of swift-markdown:

as far as i am concerned, yours is now the official repository, since the original package is unusable.

1 Like

Yes, that explanation for its rejection sounds more familiar—almost as though I encountered it too somewhere... :wink:

1 Like

Big +1. At the very least, a package maintainer should be able to pin to specific commit hashes for dependencies (and thus take on the responsibility of updating and ensuring compatibility manually) and have SPM shut up about semantic releases when people in turn consume that package.

1 Like

Semantic versioning is not even an international standard, it is just a "common method"

Nowadays a lot of repositories and projects use other methods, for example the "year.version"
method (like 2023.1, 2023.2 ecc...)