What's the reason for including the GitHub run num...

# kotest-contributors

[Adam S]

What's the reason for including the GitHub run number in the Kotest snapshot version? https://github.com/kotest/kotest/blob/0ead70d13899bc4389739369a510c64f0af69491/buildSrc/src/main/kotlin/Ci.kt#L9-L12

private val githubBuildNumber = System.getenv("GITHUB_RUN_NUMBER")

   private val snapshotVersion = when (githubBuildNumber) {
      null -> "$snapshotBase-LOCAL"
      else -> "$snapshotBase.${githubBuildNumber}-SNAPSHOT"
   }

[Adam S]

it'd help with caching & task avoidance if the version was just X.Y.Z-SNAPSHOT

[sam]

it has to be unique in maven snapshots right ?

[Adam S]

nope

[sam]

it'll overwrite ?

[Adam S]

-SNAPSHOT versions get a timestamp

[Adam S]

yeah

[sam]

is the timestamp available to users via the maven coordinates?

[sam]

might be jarring to use a snapshot and it keep changing on you

[Adam S]

hmmm I'm not sure if older snapshots can be selected

[sam]

can we use a consistent version during the build and just overrride it when publishing ?

[Adam S]

I think snapshot versions changing without warning are just part of the fun of using -SNAPSHOT 🙃

[Adam S]

although Gradle will cache snapshot versions, and the cache-duration is configurable by users

[sam]

you could argue that a snapshot is changing, but you could also argue it just means a very early snap of the current development state

[sam]

I think the value in having it not change on users is more than speeding our builds up ?

[Adam S]

> can we use a consistent version during the build and just overrride it when publishing ?
Well... during local development it's actually okay, because it'll be X.Y.Z-LOCAL

[Adam S]

oh it's not just speeding up our builds

[Adam S]

in my own projects, as a Kotest user, I want to be able to use the latest snapshot. I would normally do that by depending on io.kotest:whatever:1.2.3-SNAPSHOT

[Adam S]

or even io.kotest:whatever:latest.integration

[Adam S]

and then Gradle will cache a version for 24 hours (by default)

[sam]

it would cache it even if it's 1.2.3.4-snapshot?

[sam]

like the current naming schema still gets cached ?

[Adam S]

yes it will

[Adam S]

Gradle caches everything

[Adam S]

but there's no Kotest version for 1.2.3-SNAPSHOT, I'd have to write io.kotest:whatever:1.2.3+-SNAPSHOT

[sam]

you can do 1.2.3.4-SNAPSHOT

[Adam S]

or is <major>.<minor>.<patch>.<build-id>-SNAPSHOT valid semver? 🤔

[sam]

its not semver if you're strictly talking about 1.2.3 but it's a version number that's consistent and a user can enter it

[sam]

eg https://s01.oss.sonatype.org/content/repositories/snapshots/io/kotest/kotest-framework-engine-jvm/

[sam]

so I can do 5.10.0.1467-SNAPSHOT if I want and it'll be cached then and it won't change on it

[sam]

we link to the snapshots from the homepage

[Adam S]

you can do 1.2.3.4-SNAPSHOT

but what if I want to automatically select the latest version? :)

[sam]

well you're out of luck 😉

[Adam S]

hmmm I think that when publishing a SNAPSHOT version, each release automatically gets a distinct version

https://s01.oss.sonatype.org/content/repositories/snapshots/io/kotest/kotest-framework-engine-jvm/5.9.0.1451-SNAPSHOT/maven-metadata.xml

<snapshotVersion>
<extension>pom</extension>
<value>5.9.0.1451-20240511.091617-1</value>
<updated>20240511091617</updated>
</snapshotVersion>

[Adam S]

so -SNAPSHOT is just a shortcut for "check maven-metadata.xml, select the highest timestamp"

[sam]

if you can also reference it by timestamp, then you can get best of all worlds

[Adam S]

ah yeah, look in the Dokkatoo metadata

https://s01.oss.sonatype.org/content/repositories/snapshots/dev/adamko/dokkatoo/dokkatoo-plugin/2.4.0-SNAPSHOT/maven-metadata.xml

it even has the build number, 38

[Adam S]

ah I remember, every time you publish a SNAPSHOT maven-metadata.xml gets overridden

[Adam S]

but every SNAPSHOT version gets (automatically) a distinct, specific version

[Adam S]

I'll see if that works as expected...

[Adam S]

yes, it does

[Adam S]

so, Kotest could remove the GitHub run ID (it's useful info though, we could add it to the POM instead? Append it to the description?), and then users could use either

• a general snapshot, to get the latest, e.g. 5.10.0-SNAPSHOT
• or a specific snapshot 5.9.0-20240511.091617-1451 (unchanging)

[sam]

ok we can do this when we start on 6.0, which can be today if we want. Can cut a 5.9.2 and make a release branch and then start filing our boots on master for 6.0 changes

[Adam S]

sure, sounds good!

[sam]

I got most of the stuff that could be merged, merged yesterday

[sam]

there's a few things that could go in but have conflicts.

[sam]

and most of the rest is just WIP stuff

[Adam S]

okay, I made a PR with the versioning change for 6.0

https://github.com/kotest/kotest/pull/4193

[Adam S]

and one that can be merged for v5 that will fix https://github.com/kotest/kotest/issues/4012#issuecomment-2241524654

https://github.com/kotest/kotest/pull/4194

[Oliver.O]

Do snapshot publishing changes need to wait for 5.9.2?

[sam]

We can publish from a branch right?

[Oliver.O]

I guess so. But even if not, snapshot publishing is not that essential at this stage, or am I missing something?

[sam]

Right it's not