How do we use `manualVersions` in the latest versi...

# touchlab-tools

[Eric Williams]

How do we use manualVersions in the latest version of KMMBridge? I'm update from 0.3.1 to 0.5.5. I have

kmmbridge {
    mavenPublishArtifacts()
    manualVersions()
    spm()
}

set in my shared libs gradle but the autoversioning workflow seems to be called still. I have LIBRARY_VERSION=1.1.0 set in gradle.properties

[kpgalligan]

The workflow assumes autoversion. The whole "versioning" concept in 0.3.x was too complex and was inside the Gradle plugin itself, which is difficult because changing the Gradle version, from within a Gradle plugin, is not a great plan. Version 0.5.x was a significant change. Most versioning schemes were removed, and it was assumed you'd use "manual", which means the plugin just uses the Gradle version.
The "workflow" for 0.5.x implements autoversion in the workflow, not inside KMMBridge. It assumes you want autoversion support. As a workaround, you could just have LIBRARY_VERSION=1.1 in Gradle props as a "filler", and keep the actual version you want to use in a separate Gradle prop (or somewhere else in your Gradle config). KMMBridge just uses the Gradle version, so it would be fine. Obviously, some kind of param to skip autoversion in the workflow would make more sense, but the original goal of the workflow was more of a "template" that should be forked if you need to do other things, but most people use it directly. It's not super configurable.
The KMMBridge 1.x release (coming soon) trimmed more of this. "autoversion" was for a specific use case of frequently publishing dev builds. It's been the cause of much confusion around KMMBridge and config. There's an updated workflow that only handles SPM (which is what the vast majority of users ask for), and just skips the whole "autoversion" concept altogether.
Docs should be more streamlined in the new build. More about what publishing KMP XCFrameworks and KMMBridge actually is and does. Old docs were talking about the workflow, linking out to blog posts, etc. Hard to follow. New docs are more "KMMBridge publishes Xcode dependencies, here's a template, here's how to use it. If you need custom support, here are the things you'll need to extend".
Coming from 0.3.1 to the 0.5x, and certainly the 1.0.x, KMMBridge will be fairly different. The OG KMMBridge was carved out of a larger and more complex tool that got shelved, and retained a lot of it's structure (it was more about team coordination than "publishing Frameworks"). 0.3.x had way too much going on inside the plugin. 0.5.x removed a lot of that, and 1.0.x removes more still.
We're also switching our recommendations for teams getting started with KMP. The default won't be "binary dependencies". As such, KMMBridge will be more focused on strictly "publishing" and less on dev workflows. We've found that many teams have different needs for "dev workflows" anyway, so the autoversion concept wasn't necessarily useful.

[Eric Williams]

LIBRARY_VERSION=1.1 works fine for us!