Stuck at v2.9.0.beta1 – Now Running 3.4.0.beta4-dev after Disabling Hooks: How Can I Lock to Stable Releases?

Support
1

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!

2

You can take a look at this guide:

3

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.

1 Like
4

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:

5

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)

1 Like
6

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.

7

Does the line with tests-passed in it start with a #?

8

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)
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)980×395 13.4 KB

9

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

10

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:

  1. 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?
  2. 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…

11

Hmm. Doesn’t look like it to me:

image
image358×114 18.1 KB

12

Doh! Maybe I looked too fast on my phone. I have no explanation for how I missed that nor how the site is now running 3.5.0.beta1-dev.

2 Likes