https://kotlinlang.org logo
Join Slack
Powered by
(moved from <https://kotlinlang.slack.com/archives...
# terpal
a
(moved from https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1747831930795309) Hey @phldavies. So I use both Terpal and Terpal-SQL in ExoQuery so I'll need to keep versioning both for upcoming Kotlin versions.
p
Does the Terpal not abstract from the differences as far as Terpal-SQL is concerned? Does a new Terpal-SQL release need to be cut to use the newly published Terpal version that's been built against the new kotlin version?
a
You're right. Terpal-SQL versions do not need to be incremented with Kotlin versions. That's why I came up with the versioning-scheme that I did.
I agree that 
<PluginVersion>.PL-<KotlinVersion>
is probably better but I decided to go with the KSP way of doing things thinking that perhaps people are more familiar with it and they'll build special handling into dependabot for it. I'm still not sure that it's the right choice though.
p
I think for the plugin, versioning as you actually makes sense to follow KSP's lead as the community will follow. I'm just not sure the consumer libraries need to be versioned explicitly against a specific plugin verison. An example would be releasing a path release of Terpal 2.0.1.PL - you'll release (just like ksp just did) versions for 
2.2.0-RC-2.0.1
, 
2.1.21-2.0.1
and 
2.1.20-2.0.1
(and likely more ... ) Now you have Terpal-SQL in the wild already as 
2.0.0.PL-3.2.1
- do you release 
2.0.1.PL-3.2.1
?
a
Now you have Terpal-SQL in the wild already as 
2.0.0.PL-3.2.1
- do you release 
2.0.1.PL-3.2.1
?
Exactly!
That way I only need to publish a PL version for every kotlin version.
p
Will you plan on maintaining a Terpal-SQL that's built against an older plugin version (potentially with breaking changes)? - i.e. release a 
3.3.0
of Terpal-SQL against both 
2.0.0.PL
and 
3.0.0.PL
? or will likely only target the latest branch/stream of the plugin.
That way I only need to publish a PL version for every kotlin version.
but you'll also need to release a new library version for every library every time you release a new PL version
Despite, I would assume, Terpal-SQL 
2.0.0.PL-3.2.1
being perfectly compatible with Terpal 
2.1.21-2.0.1.PL
(assuming 
2.0.1.PL
is non-breaking, which the version bump would indicate)
a
Interesting point! Yes that should work
Maybe that's too complicated though? Perhaps I should drop minor versions in the PL entirely.
(I'm not 100% sure about older versions going forward. I think I've had to do what you describe at least once though.)
p
I suppose what I'm angling towards is simplifying the Terpal-SQL (and similar) libraries versioning to just their own version - they'll depend on a minimum PL version, but not explicitly on a single PL version which the current versioning scheme implies. Terpal can release new versions as needed against multiple kotlin versions - everything else is just standard library versioning. The question of 
kotlinVer-pluginVer
or 
pluginVer-kotlinVer
then becomes one of convenience/convention - by going 
pluginVer-kotlinVer
you potentially use version constraints against the pluginVer from the libraries (i.e. 
[2.0, 3.0)
)
As for fixing something in a Terpal-SQL version against an older PL version - that could be a case for backporting to the affected version of Terpal-SQL that supports that PL version?
a
they'll depend on a minimum PL version, but not explicitly on a single PL version which the current versioning scheme implies.
What that inevitably leads to is compatibility tables which I want to avoid at all costs.
p
you kinda have it already, just spread out in the versioning of the released libraries.
a
It's a "implicit" table that is encoded into the versions. Explicit version-compatibility tables drive me nuts because people move them around, they're never maintained well, and inevitably errors creep in. First they're in the README, they someone will move them to the microsite, then the microsite will be down and you'll need to hunt them down from some file in the source tree of which there are multiple versions. I have too many scars from this to attempt it again.
I agree that the 
.PL
version should be simpler though. Dropping the minor-version is probably a good idea.
(Another thing I'm considering is having the plugin detect whether your project is Java and including the right version of exoquery-runner-jdbc into it automatically (same for the native and android versions). The only trouble with that is, what happens if in the future I want to support vertex/r2dbc instead of JDBC. Maybe it's fine to have both libraries since exoquery-runner-jdbc doesn't actually include a driver and it's just stuff from javax.sql anyway? Need to think about that.)
(P.S.S I have no freaking clue why Exposed decided to build in R2DBC support. It's literally a dead protocol. They'd be much better going with Vertx instead.)
laugh cry face palm 1
p
I do wonder if gradle variants can help navigate this a bit but I'll be honest I've not dug into it.
a
Sounds interesting enough, I'll have a look.
c
> I do wonder if gradle variants can help navigate this a bit but I'll be honest I've not dug into it. There is no attribute for "the version of Kotlin" so I doubt they would help. If you had to select an artifact depending on the Java version they would help though.
p
It may not help for selecting the plugin but it might help for selecting the appropriate libraries for the plugin version
a
@phldavies After re-thinking how I use the versions in general, I'm starting to think you're right 😉
I think perhaps should I drop the non-PL part of the version entirely.
(At that point the ".PL" is kinda irrelevant but killing it outright would destroy any sense of continuity of my versions at all.)
👍 1
Open in Slack
PreviousNext
Powered by