https://kotlinlang.org logo
Title
z

Zac Sweers

09/25/2021, 8:00 PM
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

yigit

09/25/2021, 8:14 PM
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

Zac Sweers

09/25/2021, 8:21 PM
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

Ting-Yuan Huang

09/25/2021, 11:06 PM
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

Fudge

09/26/2021, 11:26 AM
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

Zac Sweers

09/26/2021, 5:19 PM
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

Ting-Yuan Huang

09/27/2021, 11:27 PM
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

Zac Sweers

09/28/2021, 3:42 PM
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
t

Ting-Yuan Huang

10/06/2021, 6:55 PM
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.
z

Zac Sweers

10/06/2021, 7:24 PM
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

Ting-Yuan Huang

10/06/2021, 8:13 PM
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
👍 1
z

Zac Sweers

10/06/2021, 8:14 PM
ah, woof
t

Ting-Yuan Huang

10/06/2021, 8:16 PM
Yeah, so it looks like
2.0.0-M1
is the better choice among other options. 🤷
z

Zac Sweers

10/06/2021, 8:17 PM
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

Ting-Yuan Huang

10/06/2021, 8:20 PM
Thanks, I'll make a list in the home page for that.
z

Zac Sweers

10/07/2021, 4:32 AM
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

Ting-Yuan Huang

10/07/2021, 4:33 AM
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"
:nice: 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

glureau

10/07/2021, 6:20 AM
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

Zac Sweers

10/07/2021, 2:52 PM
maybe but how would you indicate semver for ksp in that case?