@ChipWolf Ok one second: this was done by release-please automatically, so there's a problem with that.
https://github.com/headlesshq/mc-runtime-test/pull/27/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R82

Oh hah it's the release-please comments in the markdown file. Instead of using the block comments we could just use the inline one like in action.yml, but because it's in a code block it'll unfortunately be visible to the end user.

I used the block comments to avoid ambiguity, but alas

I see, same issue as this: googleapis/release-please#2345
It sadly does not seem possible to define an own VersionUpdater really.

We could define the code block with html like this

<!-- x-release-please-start-version -->
<pre>
<code class="language-yml">
... yaml stuff

But the yaml syntax highlighting wont work.
I also tried to highlight it manually but within a code block I cannot add color -_-

I think I will just update the version string manually within the README now?

I think I will try a workflow that runs after release-please and fixes the readme

I think I will try a workflow that runs after release-please and fixes the readme

sed -i -E 's/^(\s+)mc: .+$/\1mc: 1.21.4/' README.md

• ^(\s+): Captures the leading whitespace into a group (\1).
• mc: .+$: Matches mc: followed by at least one character (.+) up to the end of the line ($).
• \1mc: 1.21.4: Replaces the match with the captured whitespace followed by mc: 1.21.4.

@3arthqu4ke I've put a good amount of thought into this

In theory, we should only have the major version referenced in the README, i.e. headlesshq/mc-runtime-test@v3, as most users don't keep their actions updated at any reasonable cadence.

To achieve this we're going to have to do some trickery in the release pipeline, I'll be setting up a PR for this soon

We should also assess which tags are in use and push deprecated notices to them all.

For now, that last commit should do the trick @3arthqu4ke