RFC: A new versioning strategy for Discourse

[david (David Taylor)]

@schneeland

What’s not quite clear to me yet is how the upgrade process will work for the release and esr branches (latest seems straight-forward).

With the current launcher tooling, and this new branch structure, you could have control over upgrade timing by doing something like:

1. v2026.02 released
2. You set version: release/v2026.02 in your app.yml file
3. v2026.03 released
4. You run a rebuild. You still get 2026.02, with any recent security fixes
5. When ready, you switch to version: release/v2026.03 in app.yml

But manually editing that app.yml every month is really not ideal, so hopefully we’ll be able to design a system which makes the process more user friendly.

@schneeland

my intuition would be that both normal and esr releases receive at least a bit of extra testing

The process in the OP does allow us to treat the branches as ‘release candidates’ before actually marking them as a release. I’m not sure exactly if/how we’ll use that capability at this stage - I think it’s something that will evolve as we get used to the new system.

@schneeland

Lastly, I am wondering if monthly releases are actually “too fast”.

We’re trying to strike a balance here between the velocity of Discourse development, and the stability for people with extensive customizations. Having a 3+ month delay on getting features into the hands of our customers isn’t an option. If anything, monthly is on the slow side for us. At the moment we still intend to use latest for the majority of our hosting.

But of course, for people hosting Discourse themselves, I understand the desire to have less frequent change. So that’s where the ESR releases come in.