Not displaying latest version for package

[calda]

Hey folks, I recently added my package CGPathIntersection to the index. It shows version 3.0.2 as the latest version, but the current version is 4.0. (There was also a 3.1 release that never appeared on SPI).

These are releases that I cut / tagged on the GitHub releases page. Is this a configuration issue on my end, or a bug in SPI?

[finestructure]

Hi Cal, thanks for the report! I haven't had a chance yet to check in detail but I suspect it's because the versions aren't valid SemVer. It should be 4.0.0.

We could be more lenient here if that's in fact the problem!

[finestructure]

Yes, I can confirm that we're parsing git tags with strict SemanticVersion requirements, which is why these tags are getting filtered out.

On second thought, I don't think it'd be a simple change to be more lenient. We would definitely need to promote a tag to a full SemVer in order to handle it internally - it's a core type. While we could potentially promote 4.0 to 4.0.0, there's nothing stopping a repo from having both 4.0 and 4.0.0 for some reason, gaining a 4.0.0 perhaps after we've already promoted 4.0, and then we'd need to deal with disambiguation etc. It'd be quite messy and unlikely to happen to be honest.

The simplest fix would be if you tagged those versions 4.0.0 and 3.1.0. Would that work for you?

[calda]

I added a 4.0.0 tag, and SPI displays it as-expected now: https://swiftpackageindex.com/calda/CGPathIntersection 👍🏻

[daveverwer]

Interestingly, the reason we originally used strict rules is that Xcode used those rules when adding a package. If you had pasted this package's URL into Xcode's "Add Package" window, it would have offered to add v3.0.2, as it was the last version with a strict semantic version number.

I just tested it again using Xcode 13.2.1 and it looks like Apple's implementation has changed and they're now recognising non-strict semantic versions in that screen and it finds 4.0 (which it converts to 4.0.0):

So, we should add support for expanding version numbers like this in the package index too. The idea was to match what Xcode did, and that's still what I'd like to do. I'll add an issue for this next week.

[daveverwer]

Your comment you just posted above is interesting. Before I checked Xcode's functionality I made sure you hadn't updated it yet and saw it was still released as 4.0 on GitHub:

But now you posted above, I checked again and see that the tag had already been updated and was 4.0.0 where I had only looked at the release title. I need to find another package that uses short version numbers and verify Xcode's behaviour before logging an issue to change our behaviour.

[calda]

aha, yes, sorry for the confusion!

[calda]

It looks like Swift Package Manager itself requires strict semantic version numbers. When I add this to a sample Package.swift:

.package(
  name: "CGPathIntersection",
  url: "https://github.com/calda/CGPathIntersection.git",
  from: "4.0")

I get an error when I run swift build:

$ swift build
error: manifest parse error(s):
Invalid semantic version string '4.0'

TIL! So this behavior seems perfectly reasonable. Thanks for this info.

[finestructure]

I need to find another package that uses short version numbers

Just tag LeftPad with one :)

[daveverwer]

Yep. I just tested this and with LeftPad 2.0, Xcode still imports v1.1.0.

[daveverwer]

I'll close this now as I believe we're still doing the right thing!

Thanks so much for the report though, Cal. It's always good to check as things can change!

[calda]

Aha! Looks like this is supported by SPM in Swift 5.6. From the release notes:

Semantic version dependencies can now be resolved against Git tag names that contain only major and minor version identifiers. A tag with the form X.Y will be treated as X.Y.0. This improves compatibility with existing repositories.

[calda]

I wonder what SPM does if a repo defines both a 1.0 and a 1.0.0 tag 🤔

[finestructure]

Yeah, I saw that too this morning, thanks for raising this!

I think we'll have to do the same and "promote" x.y tags to x.y.0 when we encounter them.

With respect to the edge case of both x.y and x.y.0 being present we should check how SPM is dealing with that.

They might just error out, which is not something we'd want to do when ingesting a package.

I think in that case for us the more specific tag x.y.0 should "win" and x.y be disregarded entirely.

The only other option I see, and it would certainly be the cleanest, would be to make the patch field optional in SemanticVersion. I suspect that change wouldn't be trivial to handle though but it might be worth a try.