I was reported that feedback FB9833870 (SemVer issues with package dependencies in SPM) was resolved as "Investigation complete - Works as currently designed". I regret that this resolution was chosen, and I look for support from the SPM team and other community members so that it is reconsidered.
The initial problem is that Swift Playgrounds for iPad does not recognize semantic version tags prefixed with "v". It displays an error message, telling that the "package does not have version tags" (screenshot).
This is an incorrect and misleading error message. Tagging git commits with "v..." tags is a valid way to express semantic versions. Quoting https://semver.org:
[...] prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. [...] Example:
git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.
This incorrect behavior is specific to Swift Playgrounds for iPad. SPM in the command line, SPM embedded in Xcode, and other package managers such as CocoaPods deal nicely with "v..." tags.
Many repositories in the wild use "v..." tags. Some of them are quite popular. Their tagging scheme predates the existence of SPM and Swift Playgrounds for iPad by several years. For example: Realm, KeychainAccess, AudioKit, GRDB, ...
Library maintainers do not want to retag their libraries, since this could break the workflow of existing users who rely on specific tags/commits. The job of library maintainers is indeed to protect their users and avoid breaking changes that can be prevented. Support from tooling would be appreciated.
An option for library maintainers would be to dual tag their libraries (tag a commit with both
1.2.3). But those would create new problems. SPM is known for not supporting this (evidence). Dual tagging creates the opportunity for conflicting tags (if
1.2.3 do not tag the same commit). Dual tagging creates difficulties for programs which process tags. And finally, forcing library maintainers to change their tag policy would be a surprising signal in the calm sea of tagging schemes.
All in all, I wrote this report and arguments because I hope that FB9833870 and other similar feedbacks are reconsidered. Thanks for reading!