What is the release versioning strategy ? Is there a long-term upgrade path?

[hubyhuby]

Hi there,

We are making the jump to self-hosted Twenty this week. Before we do, I have two concerns regarding the update process and long-term maintenance.

1) Release versioning and cadence

The versioning logic for Twenty CRM is unclear to me. Most open-source projects follow standard Semantic Versioning — 2.X.Y, where X introduces new features and Y covers minor improvements and bug fixes. With Twenty CRM, I'm seeing versions like 2.7.0, 2.8.0, 2.8.1, 2.8.2, and 2.8.3 all appearing within the same 7 days. Could you help clarify what drives this cadence and how stable a given release is considered to be at the time of publication?

2) Upgrade path and lifecycle planning

A CRM sits at the core of a company's operations, it cannot be out of order for 8 hours, so being able to plan ahead around update policies and version lifecycle is critical. Other mature open-source projects — such as Ubuntu or SuiteCRM — publish roadmaps and clearly distinguish between short-lived versions and LTS (Long-Term Support) releases, providing a reliable upgrade path.
Does Twenty CRM have a similar strategy or a published roadmap that would allow us to plan upgrades with confidence over the long term?

Thanks in advance for your guidances & answers.

[hubyhuby]

I understand that Twenty CRM is an agile, fast-moving startup — and that's actually one of the things we appreciate about it: it's innovative and ships features quickly. That said, I think there's a sweet spot to find here.

From a self-hosting perspective, absorbing one meaningful update per month feels manageable and acceptable for a production CRM. A potential breaking change every 7 days, however, is a bit hard on the nerves & maintenance time. 😄 An idea could be like on the kernel a 2.7.X is unstable and a 2.8.X is the stable version of this month... So when I do the update for this month I take the 2.8... So my upgrade path goes from 2.6=>2.8=>2.10

I have also the feeling that Semantic versioning is working "backward" like in 2.X.Y the Y are the betas (in tags version) and the X.0 are the tested versions as they appear in "Realease". So my understand to this point is we should install on runing instances only 2.X.0 ???

Is there any guidance on which releases are considered more "battle-tested" for self-hosters who prioritize stability over cutting-edge features?

[prastoin]

Hey there, very legitimate questions let me clarify !

Small introduction regarding the upgrade history and current status
Previously we were requiring incremental upgrade, for example to get your 1.0 instance up to 1.10 you would have had to perform 10 upgrades for each in between minor versions for the migrations to be run incrementally
Starting from 1.24 we now support and maintain cross version upgrade.
Which means you can upgrade your instance from 1.24 to 2.8 in one tag mutation and one upgrade process. ( Unless we explicitly declare we're breaking the upgrade sequence, should happen once a year every time we increment the major so we can get rid of retro comp decorators / "deadcode" allowing the upgrade sequence support )

1. Release versioning and cadence

Twenty versions are major.minor based. We keep the patch for hot fixes.
We usually recommend always consuming the latest patched version through major.minor versions for dev env and specific patch for your production. That's up to you.
What motivates a minor bump on our side are database migrations and our motivation to release features asap and stay agile

2. Upgrade path and lifecycle planning

We're not planning to maintain any LTS image, though you could decide to stay on a given twenty version for a month and upgrade to the latest one ( or any ) punctually

For the moment we still allow us to perform forward breaking changes, this means that when you're performing a cross-version upgrade you're prone to downtime and we would recommend configuring a maintenance page on site during the upgrade. If you don't have thousands of workspace it shouldn't be that long anyway

If you can't accept any second of downtime you would have to go back to the incremental upgrade path, what we're performing on our side for our cloud solution.

Is there any guidance on which releases are considered more "battle-tested" for self-hosters who prioritize stability over cutting-edge features?

You can also choose not to be on the latest twenty version but two versions in prior, again that's quite up to you.
Note that the cloud solution is always on the twenty latest version, we do take care of not performing any "manual" fixes if we encounter an issue while releasing a twenty version, though by definition as the workspaces and data are not deterministic you might always encounter some edge cases on your side
If you're facing issue while upgrading your staging instance feel free to reach out, we're usually very reactive on discord

have also the feeling that Semantic versioning is working "backward" like in 2.X.Y the Y are the betas (in tags version) and the X.0 are the tested versions as they appear in "Realease"

I got your point, we should probably stop surfacing only the .0 as official "Releases" and treat every major.minor.patch the same. No, it's not backwards, and the patched versions aren't canary or beta, they're the latest
Since the cross-version upgrade release we've stopped publishing cloud-only patches, so Docker Hub and GitHub releases should always be symmetric.

[hubyhuby]

Thanks for the advances answer, this clarifies a lot of things.

So if I understand clearly as of today we have 2.8.0 tagged as "released",
but to start an installation self hosted you would recomand to use the latest tagged "v2.8.3" (unreleased somehow).

For the next update: if we have 2.9.0 released and 2.9.5 unreleased, we will update to 2.9.5.

[prastoin]

Yes exactly, patched versions are production ready and contains either hot bug fixes or security patches ( if critical ) too
2.8.3 has been released please see DockerHub: https://hub.docker.com/layers/twentycrm/twenty/v2.8.3/images/sha256-181ec8e25aaf952d002a53b94f289789daaeeed3edb54fbf3378fb7915237c1e
Starting from 2.9 we will start publishing GitHub releases patch agnostically as this seems to be quite misleading across the community

[prastoin]

You're welcome !