A modern programming language that makes developers happier.

kotlinlang

image.png

:rocket: ExoQuery <https://central.sonatype.com/artifact/io.exoquery/exoquery-plugin-kotlin/2.1.20-1.2.5.PL|1.2.5> is out, supporting value-classes out of the box!
You can encode, decode, and lift them via a `params` function the same way as primitives.
:bulb: This is perfect for typed-id patterns like this:

Nice. Just curious, any specific reason for using different versioning schemes for the plugin and runners?

So the runners don't depend on kotlin version. Plugins are `&lt;KotlinVersion&gt;-&lt;PluginVersion&gt;.PL` because they depend on kotlin version. The runners are `&lt;PluginVersion&gt;.PL-&lt;RunnerVersion&gt;` because they depend on the plugin-version but not the Kotlin version.

In the long run it means that I can move forward runners without a dependence on the Kotlin version and without the need for complex version-compatibility tables.

In the long-run I'll be releasing plugins for multiple kotlin versions at the same time e.g. `2.1.20-1.2.5.PL` and `2.2.0-1.2.5.PL` will exist simultaneously. The runners for both of them will be `1.2.5.PL-X.Y.Z` .

For the next few months I'll be on a very fast cadence so everything is versioned together. That'll change as ExoQuery becomes more mature.

It would make more sense to have the artefact's primary version come first, and the related version second (i.e. `&lt;PluginVersion&gt;.PL-&lt;KotlinVersion&gt;` and `&lt;RunnerVersion&gt;-&lt;PluginVersion&gt;.PL` as semver based tooling would better understand it. That said, would gradle variants help in any way here?

KSP’s gradle plugin does what Phil suggests, for the record. 

<@U7051GKRQ> I thought KSP puts the Kotlin version first which is what I copied. Here’s an example: <https://central.sonatype.com/artifact/com.google.devtools.ksp/com.google.devtools.ksp.gradle.plugin/versions|https://central.sonatype.com/artifact/com.google.devtools.ksp/com.google.devtools.ksp.gradle.plugin/versions>

Am I missing something?

<@U7051GKRQ> <@UVAR0DXP0> could you show me an example of what you’re talking about?

Indeed if KSP is a good example, they do kotlinVer-kspVer - but I don't believe there's the same coupling of kspVer to consuming libraries as is implied by the terpal plugin version

My reason for mentioning it is we have to be careful with dependabot updates for terpal-sql but that may just be because previously there was no `.PL` suffix on the plugin version number (it keeps wanting to move to 2.0.0-0.3.1)

An example where this may be an issue is when a new terpal-sql is released against old and new plugin versions, and you're still on the older plugin version, i.e. `2.1.0.PL-4.0.0` and `2.0.0.PL-4.0.0`  dependency tools may suggest a move to the `2.1.0.PL-4.0.0` version

Yeah, terpal-sql was unfortunately a bit of a guinea-pig until I figured these things out.

The question comes down to this: should something like `2.0.20-1.0.0-RC3` come before or after `2.0.10-1.0.0.PL`?

Possibly worth moving to <#C07CVTQ6WBG|> rather than hijacking your feed thread on an awesome new feature - but will there be releases of libraries like terpal-sql maintained against multiple plugin versions or are they likely to just target the latest plugin, with the plugin handling the distinction between kotlin version moving forward. If so, you may not need the plugin version in the library version at all. I think the plugin dependency itself is a special case as it's very coupled to the kotlin compiler and isn't likely to change as often as the consuming library?

Good point! I'm moving to <#C07CVTQ6WBG|>