Updating / Rebuilding Docker Container results in v3.5.2 instead of v2025.11.0

We updated an existing Discourse setup like we did several times before: After pulling the current revision of the discourse_docker repo we run the following command:

./launcher rebuild app

It runs through without an error and also starts the new container - looks all fine.

But examinig the HTML source of the running application, we see it’s still claiming to be a v3.5.2 (the version from before the update) - instead of the expected v2025.11.0

Our procedure is the same as with previous updates. Only thing that obviously changed is the version numbering scheme that was introduced with v2025.11.0 - maybe it’s related to this change?

I’ve checked whether in the Discourse source-code the version string was e.g. forgotten to be bumped, but that’s not the case, see the two commits:

From the output of the launcher’s rebuild command I noticed that it performs a git pull and sees/detects the new branches:

(...)
 t [tag update]          beta                    -> beta
 t [tag update]          latest-release          -> latest-release
 * [new tag]             release                 -> release
 * [new tag]             v2025.11.0              -> v2025.11.0
 * [new tag]             v2025.12.0-latest       -> v2025.12.0-latest
 * [new tag]             v3.5.2                  -> v3.5.2
 * [new tag]             v3.6.0.beta2            -> v3.6.0.beta2
Switched to a new branch 'stable'
I, [2025-12-03T12:27:14.785550 #1]  INFO -- : branch 'stable' set up to track 'origin/stable'.

Still somehow it feels like it picks the wrong (as in “not the newest”) branch. The “stable”-branch seems to contain v3.5.2 (according to lib/version.rb in that branch)

Re-read the Release Announcement for 2025.11.0 and that does indeed sound like a stable release, not just a preview / early-adopter release. The linked new versioning strategy mentions the latest branch, but I’m now not less confused on what to expect.

Am I missing something? Or can we influence which version is to be picked during the rebuild? Or is it just not working as intended for the moment and the rebuild tooling needs a change?

Not sure if that’s related, but on the Docker hub, the “latest” tag is `3.5.2` - and numerically sorted descending, this might be the newest tag for a looong time…

לייק 1

v3.5.x is the correct version for the stable branch :+1:

2025.11.0 is a monthly ‘release’, but not a ‘stable’/‘esr’ release. (we’ll be renaming stable to esr soon, as part of the new versioning strategy)

לייק 1

That’s confusing. It’d make more sense to switch everyone to the new version scheme at once, but it also makes no sense to have stable upgrade when there’s no new stable. I’ve been confused, and I like to think I’m paying attention to this stuff. I’ now remember some discussion from Richard about this but I didn’t pay close enough attention to understand.

:person_shrugging:

Thanks @david - that at least helps as I now understand I did nothing wrong.

Now remains the problem for us, how to decide what’s a “monthly release” and what’s a “stable release”?

We fetch the Atom-Feed from Github (to get notified about newly detected releases) and there 2025.11.0 and 3.5.2 show up the same way (together with many other tags).

So how / where can we easily find out your team’s intention for a given version tag?

I’m with @pfaffman here, it’s very confusing right now.

Yeah I hear you - we’re in a transition phase between two numbering/naming schemes, so things are a little hard to follow.

We are working on building a page which lists all the currently-supported versions, and their changelogs. Something along the lines of this. Hopefully that will help with questions like these.

From January 2026, we will tag a release with the ‘esr’ tag. That will be the replacement for the 6-monthly cadence of the current ‘stable’ version.

So beta has become release (it was never really ‘beta’, it was just a monthly checkpoint)

And stable will become esr, but that hasn’t happened yet

So if you want a 6-monthly cadence, you should stick with stable for now, and then use esr from January.

If you want a monthly cadence, then you can target the release tag.