I had a long-standing issue with a Discourse install that was stuck at v2.9.0.beta1—due to personal challenges, I couldn’t resolve it for years. Back then, it seemed impossible to move to v2.9.0.beta2. Recently, while troubleshooting a rebuild problem, I commented out certain hooks in my app.yml (specifically, the ones forcing a tag checkout) like so: hooks: after_code: - exec: cd: $home/plugins cmd: - git clone https://github.com/discourse/docker_manager.git - exec: cd: $home cmd: # - git fetch --depth=1 origin tag v2.9.0.beta2 --no-tags # - git checkout v2.9.0.beta2 - echo "Skipping version upgrade hook" After rebuilding, my instance unexpectedly updated to 3.4.0.beta4-dev. While I’m glad to have moved past that problem, I now want the system to continue following the 3.4.0 beta stream until a stable 3.4.x release is available—and once it is, lock into that stable version so it won’t auto-upgrade into further beta or development versions. What is the proper method to “pin” or lock the release at a stable version once it’s available, without having to revert or perform manual interventions on every rebuild? Any guidance or best practices would be much appreciated!

You can take a look at this guide: [图片] Switching between Discourse release channels / versions Self-Hosting bookmark This guide explains how to configure the release channel of your Discourse instance. person_raising_hand Required user level: System Administrator warning Console access is required. Managing your Discourse instance’s channel determines the frequency and type of updates you receive. This guide explains the channels available and provides a step-by-step approach to changing the branch on your setup. Summary Discourse offers several channels for tracking software updates: lat…

Change tests-passed to stable in your app.yml. If you don’t have that in your yml you can look at the samples directory.

Thanks, so I had: ## Which Git revision should this container use? (default: tests-passed) #version: tests-passed I updated it to be: ## Which Git revision should this container use? (default: tests-passed) version: stable After rebuild, the system is now at: 3.5.0.beta1-dev Which seems even more strange/peculiar. :thinking:

[图片] M. Reacher: After rebuild, the system is now at: 3.5.0.beta1-dev It would appear that you changed the version to stable after the rebuild. You’re beyond stable now, so you’ll need to change it to beta or tests-passed until the next stable release (and since there was one in the past week, it’ll be quite some time (typically 8-10 months)

No, unfortunately I did not… I am 100% certain of this, it was on 3.4.0.beta4-dev and then I changed the app.yml and then did the rebuild. Then 3.5.0.beta1-dev showed up. This is 100% the path that was followed… I have ZERO doubt just to be clear about this. I literally verified things prior to the actions I’ve noted.

[图片] M. Reacher: and then I changed the app.yml and then did the rebuild. Does the line with tests-passed in it start with a #?

Screenshot of the editor: [This image displays a configuration script snippet with details on setting database, Git repository, and memory settings, specifically selecting the English language and using the stable version in a system environment. (Captioned by AI)]

It’s commented out, so what you put there does not matter and the default is tests passed. When you rebuilt to rebuilt to the latest tests passed

Thanks again for your help @pfaffman. To summarize my current understanding: Our instance was running 3.4.0.beta4-dev, which is not considered a stable release. When I updated my configuration to use version: stable (with the default commented out), I expected that future rebuilds would lock the instance to the stable branch. However, because we were already on a beta version, the update continued forward—resulting in 3.5.0.beta1-dev. It appears that switching to version: stable after having advanced past the stable tag doesn’t trigger a rollback; it just means that if we were at or below stable, it would pin us to stable instead of tracking beta versions. Is that correct? Additionally, could you clarify what the recommended process is to ensure that we don’t accidentally follow the beta channel in the future? Specifically: Is leaving version: stable as the active configuration enough to ensure that, when a stable release is available, our rebuilds will lock into it—provided we haven’t already advanced past it when the stable arrives? Are there any additional steps or cleanup tasks (such as removing or modifying any other configuration elements) that we should perform to avoid inadvertently updating to beta/development versions? I’m very much wanting to lock into a stable release ASAP, but don’t want to have it jump over this again…

[图片] Jay Pfaffman: It’s commented out Hmm. Doesn’t look like it to me: [image]

卡在 v2.9.0.beta1 –禁用 Hook 后现在运行 3.4.0.beta4-dev：我如何锁定到稳定版本？

产品支持

pfaffman (Jay Pfaffman) 2025 年2 月 8 日 18:15 12

哎呀！也许我用手机看太快了。我无法解释我怎么会错过那个，也无法解释该网站现在怎么运行的是 3.5.0.beta1-dev。

话题		回复	浏览量
Secure way to configure upgrading to only stable version of forum releases? Self-hosting stable	10	1667	2024 年2 月 6 日
Is it possible to upgrade Discourse up to a number of commits in the version? Development	4	2107	2019 年6 月 25 日
Upgrade Button - Possible Window to Exploits Feature	4	1780	2014 年9 月 10 日
Switch from beta to stable releases Product Support	4	3124	2019 年9 月 5 日
How to avoid Discourse BETA version and keep only stable? Product Support	1	1020	2020 年7 月 28 日

卡在 v2.9.0.beta1 –禁用 Hook 后现在运行 3.4.0.beta4-dev：我如何锁定到稳定版本？

相关话题