and related - would y'all consider mirroring Kotlin's milestone/rc releases too? We do extensive testing against preview releases and it would be a real bummer if we lost that ability with KSP. We've caught dozens of bugs early and been able to report them before stable release that way

Hmm i thought ksp already had a future version branch but couldn't find it, maybe it is manual. Given that ksp does rapid releases following a kotlin stable, i think it makes sense to try to automate it (of course, it is more work 😁)

happy to send PRs if you're up for it! Main thing is how you want to do it - move HEAD to 1.6 or keep it on a branch until it's stable

Kotlin compiler bootstraps itself using some close-to-HEAD versions, which we call bootstrap versions. We try to keep KSP's main branch up to those bootstrap versions ~ every couple weeks. So KSP's main branch is actually the future branch. We are planning to release *-SNAPSHOT builds in the near future. For M1/M2/RC releases it might not fit though, because the snapshot builds might be already at 1.6.10 or even 1.6.20, for example. For M1/M2/RC, we probably still need to do it manually because our current workflow requires creating a release branch and updating CI. Ideas are welcome of course. Nevertheless, I agree that we should also release for Kotlin milestones and rc, either manually or automatically. There is an issue with the version string (Gradle thinks 1.5.31-1.0.0 < 1.5.31-1.0.0-beta09) and I'm trying to fix it before we can have pre-stable releases.

Have you tried

1.0.0+1.5.31

,

1.0.0-RC+1.5.31

? This syntax is common when your library version is dependant on the platform's version.

just to clarify - this isn’t an issue of gradle picking the wrong version but rather that there is an API change in 1.6-M1 that KSP will need to recompile against

Sure. We'll release for Kotlin pre-releases after resolving the version string issue. With the current versioning scheme I don't know where to insert M1/RC without confusing Gradle 😢 Will try / experiment with what @Fudge proposed.

Check out the implementation of

VersionNumber

in gradle maybe?

We are going to change the version to

2.0.0

for the next release, instead of

1.6.0-1.0.1

. We tried a range of versioning schemes and tested with Gradle's

VersionNumber

, and it seems to be the best option. Here are some examples that we tried and they didn't work (return false):

VersionNumber.parse("1.6.0-1.0.1") > VersionNumber.parse("1.6.0-1.0.1-RC")
VersionNumber.parse("1.6.0-1.0.1") > VersionNumber.parse("1.6.0-RC-1.0.1")
VersionNumber.parse("2.0.0+1.6.0") > VersionNumber.parse("2.0.0-RC+1.6.0")
VersionNumber.parse("2.0.0+1.6.0") > VersionNumber.parse("2.0.0+1.6.0-RC")

Note that the

2.0.0

release doesn't change that much; It's bumped so that it is greater than the Kotlin version prefix (1.5.31) we have currently.

what about putting the kotlin version second?

Just

2.0.0

. It'd confuse Gradle with more than 4 parts in the version. https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/util/VersionNumber.java

ah, woof

Yeah, so it looks like

2.0.0-M1

is the better choice among other options. 🤷

yeah. Fwiw I think that's worked mostly fine for other compiler plugins in the community. Regular semver + very explicit docs about what kotlin versions they support

Thanks, I'll make a list in the home page for that.

Did y'all find a way to make it work after all? https://github.com/google/ksp/releases/tag/1.6.0-M1-1.0.0

Turns out that Gradle has two implementations for version checking: 1. https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/util/internal/VersionNumber.java 2. https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/ivyservice/ivyresolve/strategy/StaticVersionComparator.java The second is consistent with the document and is used in most places in dependency resolution. The first is used in only a couple of places in dependency resolution, and many other places that I have't been able to check. Our original versioning scheme should still work. Adding "-RC" or "-M1" to compiler prefix and KSP's version should work for Gradle dependency resolution: "1.6.0-1.0.1" > "1.6.0-1.0.1-RC" > "1.6.0-RC-1.0.1" > "1.6.0-RC-1.0.1-RC"

Maybe stupid question but could we use the kotlin version number + a number patch? Like 1.5.31_7 for the 7th version of ksp compatible with the 1.5.31. Looks a bit simpler to use & remember.

maybe but how would you indicate semver for ksp in that case?