A modern programming language that makes developers happier.

kotlinlang

In <https://api.openrndr.org/> the version displayed at the top `0.1.0-dev.1+c35ad28` is not what I would like. How is that version string decided? is it gradle, dokka, something else? The hash part is correct coming from the latest commit. When I run the `dokkaHtmlMultimodule` gradle task locally the version in the produced html files is `0.4.1`. <https://github.com/openrndr/openrndr/blob/master/buildSrc/src/main/kotlin/org/openrndr/convention/dokka.gradle.kts|This> and <https://github.com/openrndr/openrndr/blob/master/.github/workflows/release-apidocs.yml|this> files are involved. Dokka version is <https://github.com/openrndr/openrndr/blob/master/gradle/libs.versions.toml|1.7.10>. In the github action logs I can read
```&gt; Configure project :
Inferred project: openrndr, version: 0.1.0-dev.1+c35ad28```

Dokka's HTML format has <https://github.com/Kotlin/dokka/tree/master/plugins/base/src/main/resources/dokka/templates|default template>. The template uses variable (in context of FreeMarker syntax, obviously) `&lt;@version/&gt;` to display the version you are talking about (it is mentioned at <https://kotlin.github.io/dokka/1.8.0-SNAPSHOT/user_guide/output-formats/html/#custom-html-pages|the very bottom of HTML output format docs>; also you can see its usage in default template <https://github.com/Kotlin/dokka/blob/master/plugins/base/src/main/resources/dokka/templates/includes/header.ftl#L16|here>). Dokka's docs also says that you can change the template variable via <https://kotlin.github.io/dokka/1.8.0-SNAPSHOT/user_guide/plugins/versioning-plugin/|versioning plugin> by specifiying corresponding parameter `version` of the plugin in your build script.

Thank you, very useful :slightly_smiling_face:
 After looking into it, I guess my question about Gradle, not Dokka:
Why is Gradle passing a different `@version` value when ran locally vs ran on github.

^ this is one way of fixing it, but it should be simpler than that as the version is taken from `moduleVersion` configuration property

Try adding this to the root buildscript file:
```tasks.withType&lt;DokkaMultiModuleTask&gt;().configureEach {
    moduleVersion.set("HEADER_VERSION_HERE")
}```

Exactly what I was going to reply :slightly_smiling_face: Ignore the received value and pass the one I want, right?

So the version itself is taken from `moduleVersion` of the MultiModule task configuration.

&gt; How is that version string decided?
The default value of `moduleVersion` is `project.version.toString()`, javadoc: <https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#getVersion--|Project#getVersion()>

How it's chosen and why it's different for github actions is beyond my understanding of Gradle, unfortunately :slightly_smiling_face:

But yeah, you can just override `moduleVersion`  with your own value

Perhaps, `version.toString()` is wrong on Dokka's end, as it can be any `Object` with any `toString()` implementation - that would explain the hash part. Although I'm not sure what types exactly Gradle can return, and what can override it.

I'll just leave here how it looks locally: `0.4.1-dev.57.uncommitted+c39fefc` It also includes the hash of the last git commit.

<@U02NK3U2Y65> are you picking it in configuration phase? Maybe the version is a property which is not set when dokka is picking it as it should be unwrapped on the task 

```@Input
val moduleVersion: Property&lt;String&gt; = project.objects.safeProperty&lt;String&gt;()
        .safeConvention(project.version.toString())
```

changing that to this should fix the issue 

```@Input
val moduleVersion: Property&lt;String&gt; = project.objects.safeProperty&lt;String&gt;()
        .safeConvention(project.provider { project.version.toString() })
```

<https://github.com/Kotlin/dokka/pull/2799|https://github.com/Kotlin/dokka/pull/2799>

On our side, <https://github.com/openrndr/openrndr/commit/9165377f842305b2aab967ee50b52af450b5e657|this> and <https://github.com/openrndr/openrndr/commit/e1c8dcfe51b9afcda4449fba4f56f4e47fcf3bd3|this> commits helped fix this. Now the version shown in the api website looks good :slightly_smiling_face: