Retag 601.0.0?

[scottrhoyt]

I've been updating a couple of libraries that support a wide range of SwiftSyntax versions using the #if canImport(SwiftSyntaxMarkerModule) method to work around breaking API changes. These packages cannot build against 601.0.0 because of a combination of breaking API changes and the missing marker module that was fixed here.

It doesn't seem helpful to have a release published that will break builds in this way, and given that it's the only notable change between 601.0.0 and 601.0.1, I'm wondering if that can be rectified.

Any chance we can either:

1. Re-tag 601.0.0 with this fix, or
2. Unpublish the 601.0.0 tag/release?

[bnbarham]

601.0.1 is a patch release and I would expect everything to be using it rather than 601.0.0 if they're using semantic versioning. Is there some reason you're seeing that isn't happening?

[scottrhoyt]

It's a fair point.

In my case, I was testing out upgrading a dependency graph by pinning against exact: "601.0.0". I was a bit perplexed as to why this wouldn't even build until I tracked down that it was missing the marker module. While this was just for testing, I later ran into the same thing when SwiftLint got pulled into the graph, and for whatever reason, also pins to 601.0.0. I have a PR out to fix that. Since using SwiftSyntax version ranges (rather than major SemVers) are common in macro modules, I suppose someone could experience the same with a version range "x.x.x"..."601.0.0".

Spending some time working through this, it makes me wonder if there is more harm than good in leaving a release published that breaks macro module builds so readily?

[bnbarham]

I suppose someone could experience the same with a version range "x.x.x"..."601.0.0".

Ideally this would be eg. "600.0.0"..<"602.0.0". But yes, you would hit the same issue if it was a closed version range.

I would really prefer not to remove the tag/retag:

1. It won't help if the tag is already fetched. You'd have to remove it and fetch again I believe, if it doesn't error outright - would have to test that
2. This is why it's semantically versioned

[scottrhoyt]

I think we might be conflating two separate issues:

1. What's the right way to specify a SwiftSyntax dependency?
2. Should a release be left published even if it breaks builds for a large class of consumers who are following the docs?

My position is that regardless of the answer to 1, the network is better off if the answer to 2 is no.

That said, I hear your perspective, and understand that reasonable minds can disagree here, so I'll close this out. Thanks for the engagement on it.

[bnbarham]

Just to be clear, the docs use ..< for this reason (so eg. "600.0.0"..<"602.0.0"). That would match any 601.* tag and thus use 601.0.1.

I am sorry you hit this issue though :( I'll look into adding an extra check for the version marker module as part of the release action. #3101