<@U8NMFHUGJ> sorry for coming back to this old thr...

# touchlab-tools

[Vita Sokolova]

@kpgalligan sorry for coming back to this old thread, I finally decided to check how my project should work with 1.0.0, as far as I understood I should use CI script like this one to publish new versions. But I wonder if I should add any extra steps to bump LIBRARY_VERSION and push the new value to my repository?

[Vita Sokolova]

I used to rely on touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuildautoversion.yml@v1.1 and AUTOVERSION always had a new value

[kpgalligan]

I should write a follow up on how to use autoversion with the 1.0. The bad execution I had before was putting that into the default flow. Some people want it, many do not, and the ones that do are often confused by which gradle property to set.

[kpgalligan]

So, I took it out, and took out anything that CocoaPods needed, because few are asking for CocoaPods, and publishing to CocoaPods involves a lot more setup. Anyway...

[kpgalligan]

the process is conceptually simple. KMMBridge uses whatever version Gradle has set. To have automatic dev version increments, CI needs to calculate that, then pass the value into the Gradle CLI call that builds and publishes.

[kpgalligan]

In a meeting. It'll be kind of an async reply...

[kpgalligan]

In summary, here are the important parts of the CI (from the workflow you used to rely on)

- uses: touchlab/read-property@0.1
        id: versionBasePropertyValue
        with:
          file: ./gradle.properties
          property: "YOUR_VERSION_BASE_PROPERTY"

      - uses: touchlab/autoversion-nextversion@main
        id: autoversion
        with:
          versionBase: ${{ steps.versionBasePropertyValue.outputs.propVal }}

      - name: Build Main
        run: ./gradlew kmmBridgePublish -PAUTO_VERSION=${{ steps.autoversion.outputs.nextVersion }} blah blah blah

Then in the project Gradle scripts, you want to check for the passed-in AUTO_VERSION, which should only happen in CI, and set Gradle's version with that vs whatever you'd use otherwise.

the versionBasePropertyValue task just reads a value from gradle.propreties that is the base version. Task autoversion uses the base to calculate the next version.

So, conceptually not complicated, but the whole process needs a blog post or doc, and probably needs a bit of testing to make sure I'm not missing anything in the above description.