1.4.x->1.14.x?

[Wang1213]

Question

OpenCode's update strategy is frequent and aggressive, with incomprehensible bugs or confusing decisions appearing almost every few versions. Is this version jump normal?

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• I think v1.4.2 is the latest stable version who is with me? #23036: Similar concern about which version is stable, noting newer versions introduce various bugs
• Could releases be more stable? #13177: Asks whether releases could be more stable and whether a stable branch could be maintained (closed)

If your question is specifically about the version number jump (e.g., from 1.4.x to 1.14.x in the title), please clarify — but if it's about release stability and frequent regressions, these issues cover the same ground.

[Jonathan-79]

Is this intentional @thdxr ? Jumping from 1.4.11 to 1.14.17?

[coldsaber]

I think it's typo... but so it has happened, maybe in the future it will begin from 1.14.xx ....

[jeremyakers]

It would be nice to at least see some sort of explanation. Having the minor version jump from '4' to '14' makes no sense, especially since the patch (third number) version didn't reset back to 0, and also skipped several versions. (11 to 17)

[Milk0217]

更新的时候吓我一跳，后面就不会再修复了嘛

[MemberIT]

This is very strange and disrupts the semver order. It could potentially break some plugins, I think.

[ttimasdf]

What's going on with the release process? It's quite odd that all the commit hashes for tags starting from 1.14.x do not belong to any branch in this repository. I don't believe this is a typo.

• a948b1c v1.14.17
• 23fb5e0 v1.14.18
• 27db54c v1.14.19

Could you please investigate or explain what's happening with the release bot, @thdxr? Has your AI gone rogue?

[Jonathan-79]

Tags on commits not present on any branch, unexpected jumps in version numbers... and no one from the core team has stepped in to explain what's happening. I wonder whether this is a security incident and malicious code was injected in recent versions.

[ttimasdf]

Starting with v1.4.12, the version bump commit became a dangling commit and is no longer merged into the dev branch. Interestingly, as of v1.14.17 (the first version with the typo), the bot has been creating a separate version commit in the dev branch that is independent of the tagged commit.

After digging through the code, workflow files, and scripts, I found that this change was introduced in #22982 by @kitlangton to solve... well, I’m actually not sure what problem they were trying to solve.

I understand using a GitHub Actions bot to automate version bump commits; it's convenient. Since GitHub doesn't allow triggering CI from within CI, using a ghost account to bypass this limit is hacky but understandable.

But why cherry-pick commits from dev and perform "AI-assisted merge conflict resolution"? As far as I'm concerned, a "release" is meant to ship well-tested code in a frozen state, not code freshly generated by AI and pushed with --no-verify.

opencode/script/publish.ts

Lines 60 to 69 in 16caaa2

	await $`git commit -am "release: ${tag}"`
	await $`git tag -d ${tag}`.nothrow()
	await $`git tag ${tag}`
	await $`git push origin refs/tags/${tag} --force-with-lease --no-verify`
	await new Promise((resolve) => setTimeout(resolve, 5_000))
	await $`git fetch origin`
	await $`git checkout -B dev origin/dev`
	await prepareReleaseFiles()
	await $`git commit -am "sync release versions for ${tag}"`
	await $`git push origin HEAD:dev --no-verify`

It seems AI is just being used to stack more hacks onto an existing hack to solve the bugs of a hack.

[philcbu]

[modpr0be]

Ah, finally it's clear now. Updating..

[ttimasdf]

1. If the version number is still typed in by a human, then maybe we should run the release process on a human's laptop, commit with a human's account, just a slash command trigging something like /bump-version-and-push skill and everything is done under control. why bother use CI?
2. If the tag commits are out of tree, the commit graph becomes obscure and standard git operations break. e.g. comparing tags like: v1.14.19...v1.14.18 . If we can't use git operations on a git repo, why bother use git?

[laanwj]

fwiw i was really confused by tag v1.14.25 not being in the repository, and having to fetch it by commit id after figuring it out from the release page here.