https://kotlinlang.org logo
Join Slack
Powered by
and related - would y'all consider mirroring Kotli...
# ksp
z
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
y
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 😁)
z
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
t
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.
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)
f
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.
🙏 1
z
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
I’m mainly just wanting KSP to mirror kotlin releases. Snapshots would be nice but I consider the releases far more important
t
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.
z
Check out the implementation of 
VersionNumber
in gradle maybe?
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
what about putting the kotlin version second?
oh that's what you're doing
or no
I'm confused
just 
2.0.0
? Or 
1.6.0-2.0.0
?
t
👍 1
z
ah, woof
t
Yeah, so it looks like 
2.0.0-M1
is the better choice among other options. 🤷
z
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
t
Thanks, I'll make a list in the home page for that.
z
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
t
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"
👌 1
Verified by publishing libraries of those versions, and then check what's selected with ":latest.release".
👍🏼 1
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.
g
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.
z
maybe but how would you indicate semver for ksp in that case?
Open in Slack
PreviousNext
Powered by