You might remember the issue https://github.com/typesafegithub/github-workflows-kt/issues/627 where String with value

"null"

and

""

were serialized wrongly as

null

. We have the same problem with Strings that look like other scalars like ints, floats, and booleans. A String with value

"4.0"

for example is serialized as

4.0

which then is interpreted as the float

4.0

and thus given as

4

where used, for example in

${{ matrix.variant }}

. Should we finally just single-quote all single-line Strings, or introduce some more parsing to determine whether it needs quotes or not?

ugh, I’m lovin’ it… could you create a bug for it?

The root cause is

if (this is String) {
    if (lines().size > 1) {
        ScalarStyle.LITERAL
    } else if (isEmpty() || (this == "null")) {
        ScalarStyle.SINGLE_QUOTED
    } else {
        ScalarStyle.PLAIN
    }
}

which strives to produce better readable YAML output by not quoting all single-line strings. But for the price of issues like these two.

I see - I’d be keen to sacrifice readability here to get correct and simper code

Quite tedious change with all the embedded integ tests 😕

Thanks! 🙇Merged. To avoid unscheduled release, can you use the Jitpack snapshot (yeah, the coords in the docs need to be updated) from main branch to iterate on your change (I presume this issue doesn't occur in any existing workflow that you rely on)? If not, let me know, I'll prepare a release tomorrow morning

It happened in the Spock build where I want to establish the lib currently.

Sorry, a bit confused here, I need a link where this is happening

Still don't get why you'd expect 3.0 or 4.0 somewhere, I need a more precise pointer

There are "variants" for Groovy 2.5, 3.0, and 4.0. In the latest state on that PR, they are defined in

matrix.groovy

where the build script reads them and also the workflow kts files read them from.

We disabled signing for JitPack, see here. Feel free to create a bug for it

You disabled the signing task, but the publication is invalid as you specified it should be singed but then suppressed the task

Thanks for the idea! I'll definitely consider it: https://github.com/typesafegithub/github-workflows-kt/issues/774

Thanks for the idea! I'll definitely consider it

For the meantime: https://github.com/typesafegithub/github-workflows-kt/pull/775

BTW, Jitpack building worked some time ago, I wonder why it broke

Gradle update from 7.4.1 to 8.1 I guess

Thanks!

yw

Qq: have you tested the fix for JitPack?

Thanks! For the future, it's helpful to write such things in PR description :)

I opened the PR first, as that pushes the branch 😉

Btw. when anyway reworking the publishing, you should consider applying the https://github.com/gradle-nexus/publish-plugin, especially when using Sonatype to publish to Maven Central it is quite flaky without it and if wanted it can also help completely automating the release without needing to finish it on the Nexus UI.

we already use it https://github.com/typesafegithub/github-workflows-kt/blob/25657f3272f0c74ffb40364af07957f0d50ee6ad/build.gradle.kts#L5

Oh, right, I didn't see it. Just looked in

dsl-publishing

, didn't see it there and seen manual repository configuring. Controlling the version manually is absolutely in my favor. Or at least just doing it on explicit task execution and updating and committing a file. I hate it if versions are calculated from VCS history. This makes builds less reproducible, they don't work from an exported sources archive, they don't even work in a Git worktree. I usually update the patch version directly after release, also adding

-SNAPSHOT

, and bump the minor or major version with the commit that requires this bump. This then builds the proper snapshot builds for the proper next version. And before release I remove the snapshot suffix. The work around the release I usually do using the gradle-release plugin. You currently always build the last released version, even though there were additional changes. This can be quite confusing, especially when using maven local.

The work around the release I usually do using the gradle-release plugin.

I’m keen to try out this plugin one day!

You currently always build the last released version, even though there were additional changes. This can be quite confusing, especially when using maven local.

I don’t understand where’s the problem now. If one wants to use maven local, they by default work on the latest commit, and if desired, can check out a tag for a given release.

Maven local does not mean it is automatically used. Also it is unclean, confusing, and inconsistent, besides that it makes you more work. E.g. imagine I have a latest commit checked out which has still version

0.41.0

. I deploy it to Maven local to test some changes. So I test it in a workflow still having

0.41.0

declared while it actually is

0.42.0-SNAPSHOT

. I'm fine with my changes, create a PR and you merge it, next day you create a new release so I update my version and be good. Two weeks later I open another project that still uses

0.41.0

. I try to build the workflows and it fails (due to the changes in Maven local I forgot by then). Now I open a bug entry for you, or that project, or adapt to the changes according to IDE and push and thereby breaking it for the others, .......

ok, so if I understand you correctly, it’s about explicitly marking the version as non-released one (

x.y.z-SNAPSHOT

) instead of using

x.y.z

every time that looks like a released version, right?

Yes, that and also to increase the version in time when the changes require the change. This you could probabyl easily verify using the conventional commit messages. If with

!:

the major version (or minor while at

0.

) needs to be higher than in the last tag, if no

feat

, then the patch version needs to be higher, if also

feat

then the minor version needs to be higher.

increase the version in time when the changes require the change.

do you mean bumping the version in the very same commit/PR that makes a certain change? so a functional change + major/minor/patch version bump?

Yes, that's how I usually do it. If I do a breaking change, I change the major version with that commit if it was not increased already, because as soon as this commit is included, it effectively is a snapshot of the next major version.

Hmm, this approach has pros and cons. Pros: versions are semantically correct, snapshots are properly versioned. Cons: each commit is polluted with version change, one has to think about it. I know that "pollution" sounds negatively but I guess thats my current take on it :D thanks, I have to think about it

Not "each" commit is polluted, only the first feature-commit and the first breaking-commit after a release. And I personally don't see it as pollution, because the changes in that commit require that the version is increased to be correct, so the change belongs to that commit imho. But you could also split it of course, first make the commit that increases the version right before the commit introducing the first changes that needs it. 🙂

Not “each” commit is polluted, only the first feature-commit and the first breaking-commit after a release.

ok, got it now! so it also assumes that each version bump besides the “patch” part results in a release, right?

No, why? You can make 5 bugfixes and then release a bugfix release, or not and add 2 features and release then. When you increase the version number is not related to when you create the release. Unless you do want to establish some continuous publishing that releases on each commit of course or similar.

so you do “Set version to 1.0.1-SNAPSHOT” as a minimal version bump after v1.0.0 which says “there’s going to be at least a patch-like change, and if something bigger, let’s bump more significant version numbers”

so you do “Set version to 1.0.1-SNAPSHOT” as a minimal version bump after v1.0.0 which says “there’s going to be at least a patch-like change, and if something bigger, let’s bump more significant version numbers”

Exactly

Will take care of it “later” 🙂 (after work)

👌 And then you can also easily publish to Sonatype snapshot repository on each push to

main

. 🙂

are you aware of any tool (for git/GitHub) that would help enforce such versioning based on conventional commits?

this approach is very algorithmic, provided that one correctly uses conventional commits

Yes, that's what I mentioned, that you should be able to verify it by the commit messages, but no I'm not aware of any such tool.

side-note: my goal is to avoid merging via rebasing, I want to allow only squashes. I know that in case of PRs that you recently created, it would result in like 6 PRs, but there are tools for stacked PRs, e.g. Graphite. In general, this whole versioning/releasing issue is interesting, but I’d like to focus on something related to the core functionality first, and polish releasing/versioning when getting closer to v1

Hm, looks nice, that Graphite thing. Also for Spock work as Leonard also prefers doing squash merges unless forced otherwise, and I currently indeed have a PR that builds upon another PR.

ok, let’s try that in the future PRs 👍

Oh dang, what a strange decision, for the CLI you need to have Node.js installed locally. As if there were only JS developers in the world. o_O

@Vampire PTAL chore: set snapshot version 0.41.1-SNAPSHOT

• Now just add a workflow that publishes the snapshot version on each push • Then you can throw out JitPack if you like • Also please make signing optional if

SNAPSHOT

version so that you can publish to maven local without hassle • Shouldn't it already be at

0.42.0-SNAPSHOT

as you already introduced 5 new

feat

commits? • The releasing instructions talk about a

develop

branch, but there is no such branch. Or do you intend to change your process to Git Flow? • Please add to the instructions to use annotated tags and probably also update the existing tags to be annotated ones. Lightweight tags are for short-lived temporary tags, annotated tags are for persistent things like version tags. There are for example quite some commands or tools which consider annotated tags but ignore lightweight tags unless told otherwise if possible. For example try to do

git describe

.

Thanks a lot for review! I'll apply it gradually

Yes, the researchgate one is the one I currently use for projects.

ok 👌 and do I get correctly that it’s used interactively (locally), not on CI?

The atlassian one I personally don't like, because it is one of those not having a version in a file, but calculating it from Git which has imho quite some drawbacks.

ok, cool - will try to integrate with it in one of the next releases

It is Gradle tasks, so as long as you provide the necessary information like signing information and so on, you can perfectly well do it on CI, either triggered by some tag being pushed, or by some branch being pushed, or by manually triggering a workflow, ...

my biggest concern is that I need to understand really well what it’s going to do with my branches/tags/versions. I guess it’s just about going through the docs and playing on some side project

It depends on what you configure, but by default it basically makes a commit that removes

-SNAPSHOT

, creates tag on it, makes another commit that increases the patch-version and re-adds

-SNAPSHOT

.