and related - would y'all consider mirroring Kotlin's milestone/rc releases too? We do extensive tes...

# ksp

[Zac Sweers]

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

[yigit]

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 😁)

[Zac Sweers]

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

[Ting-Yuan Huang]

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.

[Ting-Yuan Huang]

I'm trying to see if we can get rid of the 1.5.31 / 1.6.0 prefix in KSP's version and let Gradle make recommendations to users. Without this prefix Gradle works as expected (1.0.0 > 1.0.0-RC > 1.0.0-M1)

[Fudge]

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.

[Zac Sweers]

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

[Zac Sweers]

I’m mainly just wanting KSP to mirror kotlin releases. Snapshots would be nice but I consider the releases far more important

[Ting-Yuan Huang]

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.

[Zac Sweers]

Check out the implementation of VersionNumber in gradle maybe?

[Zac Sweers]

Worst case, I think it would be ok to have a consistent name and tell folks interested that they need for force that version. I imagine people willing to test a prerelease version are more willing to also force that version

[Zac Sweers]

what about putting the kotlin version second?

[Zac Sweers]

oh that's what you're doing

[Zac Sweers]

or no

[Zac Sweers]

I'm confused

[Zac Sweers]

just 2.0.0? Or 1.6.0-2.0.0?

[Ting-Yuan Huang]

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

[Zac Sweers]

ah, woof

[Ting-Yuan Huang]

Yeah, so it looks like 2.0.0-M1 is the better choice among other options. 🤷

[Zac Sweers]

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

[Ting-Yuan Huang]

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

[Zac Sweers]

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

[Ting-Yuan Huang]

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"

[Ting-Yuan Huang]

Verified by publishing libraries of those versions, and then check what's selected with ":latest.release".

[Ting-Yuan Huang]

also verified with maven: https://maven.apache.org/pom.html#version-order-testing

[Ting-Yuan Huang]

Having said that, we haven't decided whether to stay with the original versioning scheme or go with the newer one. The original one is admittedly complicated.

[glureau]

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.

[Zac Sweers]

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