Version tags that include a build version are not handled properly

According to semantic versioning 2.11.3+1 and 2.11.3+2 are perfectly legal and the +2 is the newer version. I currently only have these two version tags in my project. When I only had one, adding it as a dependency worked fine:

.package(url: "https://codeberg.org/Cyberbeni/swift-utf8proc", from: "2.11.3+1"),

After I added the second tag, it stayed on the first tag after a swift package update or even after changing to from: "2.11.3+2" or exact: "2.11.3+2". After I forced it to the correct version with branch: "2.11.3+2", switching back to from: "2.11.3+2" or from: "2.11.3+1" gives an error:

error: 'swift-utf8proc': Revision 10335a120050bfcac9cb1ed132989447c800e7f3 for swift-utf8proc remoteSourceControl https://codeberg.org/Cyberbeni/swift-utf8proc version 2.11.3+1 does not match previously recorded value 66b3d1c097435fef0f1706807eefc4f9e36feac3

I'm using Swift 6.2.3 on Linux Mint 22.3

To quote the SemVer spec:

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence

So using build metadata with a + will not affect versioning and should be ignored during resolution. If you want versioning precedence you need pre-release versions

I don't really understand the reasoning behind that but ok.

I guess 1.0.0-2.11.3.1 will have to suffice for now, so I can mark releases of wrapper code and upstream library separately.

Other package managers seem to handle build metadata as I would expect it, like apt:

qemu-utils 1:8.2.2+ds-0ubuntu1.13 [Ubuntu/noble main]
├── is installed and upgradable to 1:8.2.2+ds-0ubuntu1.14
└── QEMU utilities