For version numbers, we use this setup where in `g...

# touchlab-tools

[Stylianos Gakis]

For version numbers, we use this setup where in gradle.properties we have LIB_VERSION_NAME=1.3.5-alpha and then since we know we are on -alpha, we got some code in the build.gradle.kts like this

val libVersion = buildString {
    val versionString = extra["LIB_VERSION_NAME"] as String
    append(versionString)
    if (versionString.contains("alpha").not()) return@buildString
    if (project.hasProperty("LIB_VERSION_ALPHA_TIMESTAMP").not()) return@buildString
    val alphaTimestamp = project.findProperty("LIB_VERSION_ALPHA_TIMESTAMP") as String
    if (alphaTimestamp.isBlank()) return@buildString
    append("-")
    append(alphaTimestamp)
}
version = libVersion // here we let Gradle know about the library's version

Which basically checks if we got the -alpha suffix there, in which case it looks into the property LIB_VERSION_ALPHA_TIMESTAMP which we set in GH actions through

- name: Generate alpha version timestamp
        id: time
        uses: nanzm/get-time-action@v1.1
        with:
          timeZone: 0
          format: 'YYYY-MM-DD-HH-mm-ss'

      - name: Print tag to be generated and save into env
        env:
          ORG_GRADLE_PROJECT_AUTHLIB_VERSION_ALPHA_TIMESTAMP: "${{ steps.time.outputs.time }}"
        run: |
          echo "Timestamp: $ORG_GRADLE_PROJECT_AUTHLIB_VERSION_ALPHA_TIMESTAMP"

All this to get a convenient experience around getting alpha versions with the current time-stamp.

Now trying to adopt KMMBridge, and I do not see a way for the workflow to read this value from gradle. The workflow you’ve got setup requires an input for versionBaseProperty at which point I don’t think I can get access to this versiont that I’ve setup there. Is there a way for the workflow to automatically figure out the version by which version I’ve setup to my library through gradle, but not through the gradle.properties?

[kpgalligan]

KMMBridge itself just uses the Gradle version. The workflow is more of an "opinionated" CI setup that will calculate and set up your Gradle version for the purpose of publishing. You're setting the version dynamically with your own code, which removes much of the purpose of the workflow ("autoversion" stuff). If you're setting up version yourself, you'd really want to fork the workflow and remove a lot of those steps.
Now, on the version string itself, the workflow sets a git tag with a valid semver string (ex: 2.1.32). SPM wasn't very flexible with version string formats, so I'm not sure it'll work well with -alpha in there, just FYI. Also, IIRC, it wasn't OK with more than 3 values, so something like 1.3.5.238975923457 wouldn't work either, although this is coming from memory and I'm currently on a serious lack of sleep, so some of that may not be 100% accurate.

[Stylianos Gakis]

Yeah I just went into https://github.com/touchlab/KMMBridgeGithubWorkflow/blob/main/.github/workflows/faktorybuildautoversion.yml and I noticed I could probably take this and cut like half of it and only keep the ones that I need.
Might require some trial and error though for sure. Are you aware of any OSS project which already uses KMMBridge and does this which I could get some more inspiration from?
Also yeah thanks for the version issues, I might have to fight against it a bit in this case 😄 If that is the case, would a solution be for me to do something like this?

kmmbridge {
    spm()
    manualVersions()
    versionManager.set(object : co.touchlab.faktory.versionmanager.VersionManager {
        override fun getVersion(project: Project): String {
            return authlibVersion.takeAndFormatToBeInAFormThatSpmLikes()
        }
    })
}

This, as I understand would change the version specifically for what is then generated for SPM to use right? I could wrangle the -alpha-timestamp into something which is just numbers.
Basically turn something like
1.3.5-alpha-2023-11-08-13-07-56
into
1.3.520231108130756 😅

[kpgalligan]

Are you aware of any OSS project which already uses KMMBridge and does this which I could get some more inspiration from?

No. Well, not exactly. There was a conversation in slack some weeks ago about using a forked version of the workflow, but I don't know if the project is open source, and my wife is giving me the "we're supposed to be doing Sunday night stuff" eyes right now, so I'll have to dig that up later, but it's probably in this channel.

[kpgalligan]

On the version, I don't think that would work. We never had a use case where the Gradle/maven version value and the SPM/KMMBridge version were different strings. Currently, if you set it up like that, it would (probably) fail. I think it could work, but we'd need to make a change. Basically, we don't know what the url maven creates is, so we "guess" by convention. The way some of this works is an artifact of how the plugin used to work, and that was carried over when we simplified the whole thing. VersionManager used to be much more directly responsible for things, but it's role now is less direct, and could probably use a rethink, but our use cases we had in mind were fairly simple. Just never thought there would need to be different version strings. Again, sleep deprived brain, and getting the "eyes", so I'll need to expand on this more later/tomorrow...

[kpgalligan]

Um, or not. Just fork the workflow, publish maven with your version value, and don't change the KMMBridge config. SPM does version math with git tags, so in the workflow, set the version tag to 1.3.520231108130756 The maven version will be 1.3.5-alpha-2023-11-08-13-07-56, but as far as KMMBridge is concerned, that's just part of the URL. The SPM-side of things is all handled in the git tags.

[kpgalligan]

The git tags are all set by the workflow. The earlier version of KMMBridge set those tags in the Gradle plugin itself, which was brittle, and that's why we moved most of that logic to CI instead.

[kpgalligan]

IIRC, your code is OSS, yes? If you get stuck and can push a branch, it'll be easier to see this in context.

[Stylianos Gakis]

Yes our code is OSS, I will get back to this tomorrow as well, can link the code too if I am having issues 😊 Enjoy your Sunday, I will follow up on your messages here as soon as I have some time to play more with the suggestions you've given me so far, I got things to try for sure, forking the workflow and removing some parts of it is definitely the first ones. Thank you, and say sorry to your wife from my behalf 😅

[Stylianos Gakis]

Well damn, this does seem to work I think 😄
I got this workflow down, basically copied over only the relevant I think parts from the sample workflow, and juggled some things around creating the timestamp but this time in a special manner to only contain numbers.
Then asked ChatGPT to remove the -alpha from the name of the version (Bash is my arch-nemesis and I would’ve never figured this out myself), used touchlab/read-property@main for this btw, super convenient!
And this is how the build file looks like.

So this makes a new branch for this and tags it, but then I suppose deletes the branch? But it still works to use the tag to fetch the right thing.

I was initially a bit confused as to how to find the latest version which I just generated, I looked at the dropdown of the tags available and I could look into the CI steps too to see what it was called, but idk if Xcode had a better way to find out by itself what the latest version is perhaps?

The one thing that I removed is some parts about netrc, which from your documentation is needed for Xcode to authenticate to resolve the packages. Is it that I don’t need it here because the repo is not private?

Now I guess I gotta try SKIE on top of this too 😉