Kotest 4.5 has been released. Feel free to share. <https://kotest.io/docs/changelog.html>

# kotest

[sam]

Kotest 4.5 has been released. Feel free to share. https://kotest.io/docs/changelog.html

[Peter]

is it ok to use kotest-extensions-testcontainers 4.4.3 with above?

[sam]

yes, but you might as change the dependency to be https://search.maven.org/artifact/io.kotest.extensions/kotest-extensions-testcontainers since that's what will be updated moving forward

[sam]

See changelog

[sam]

1.0.0 == 4.4.3 of that dependency

[sam]

From 4.5 onwards, the namespace for all extensions has changed to io.kotest.extensions and the versioning reset to 1.0.0.
So, for example, if you used the Spring extension, you would previously have added io.kotest:kotest-extensions-spring:4.x.y to your build. Now you would use io.kotest.extensions:kotest-extensions-spring:1.x.y

[Peter]

great, thank you!

[dave08]

Will https://github.com/jmfayard/refreshVersions be updated with the new kotest deps? It seems like they haven't released a new version for a while, and now with 4.5, too many things have changed...

[sam]

There was a PR I made months ago merged a couple of days ago, so my guess is they're back at updating it again

[sam]

I will make a new PR with all the latest changes for 4.5

[henrik]

no reason to use refreshVersions anymore now that Gradle 7 has native support for a shared versions catalog: https://docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml

[henrik]

Just use that and https://github.com/ben-manes/gradle-versions-plugin

[sam]

That's really nice

[Big Chungus]

Tbh, I still prefer refreshVersions as it's making version upgrades very easy. With catalogs you still need to find new versions manually

[dave08]

I also like it better for code complete of the most common deps...

[Big Chungus]

Catalogs generate dsl accessors too.

[dave08]

True, but they need to be created by library users... libraries with many artifacts can be hard to maintain (like the tons of Androidx libs and test deps...) apart from the actual versions. It would be nice if library authors could provide catalogs... a bit more work for the library authors (but even users can PR these things...), but would make it VERY simple to manage lots of artifacts.

[dave08]

The downside of refreshVersions is that it's not really updated so often

[Big Chungus]

That's the whole idea of catalogs, you can publish them to any maven repo, so I'd imagine big frameworks like spring will be publishing them with each version, same as BOMs

[dave08]

So really all that's missing is managing versions then...

[Big Chungus]

Another benefit of catalogs is that you can declare lib groups, so you could have all kotest artefacts under a single implementation(kotest.bundles.master)

[dave08]

That's nice... but meanwhile it might take some time for Android, Micronaut and the rest to adopt all this...

[Big Chungus]

I'm thinking of writing a plugin that'd work with catalogs and would let you run ./gradlew upgrade-interactive and allow you to interactively choose lib upgrades that are then reflected in your catalog

[sam]

Is catalogs gradle 7 only ?

[Big Chungus]

Gradle 7 and they're still in feature preview

[dave08]

I personally liked the refreshVersions approach to upgrading... having those comments there makes it easy to choose one to upgrade without having to go through all the deps and say "no".

[Big Chungus]

Agree, however not sure how that could be represented in toml

[dave08]

toml does support comments it seems. https://toml.io/en/

[dave08]

I just wonder if parsers support parsing/reading/writing them...

[Big Chungus]

Yeah, but there are multiple ways where gradle lets you declare versions in toml, so it might be tricky keeping comments consistent

[dave08]

A nice start would be the versions block... other places have version ranges AFAIK...

[dave08]

It seems like a simple properties file syntax in that block... so a simple regex could handle it with a bit of care.

[Big Chungus]

A bit limiting, but I guess that's a start.

[dave08]

Later, you could always extract hard-coded versions from the libraries block into the versions block to manage them there too...?

[dave08]

The thing is managing the naming...