Upcoming Release: CHT 5.0

Introduction

We’re excited to announce that the next major release of the CHT is being worked on right now! As we follow Semantic Versioning (SemVer) and the release includes breaking changes, this will be CHT version 5.0.0. You can see every issue currently scheduled for 5.0.0, but we wanted to make an early announcement so that the community can follow along, prepare for upgrades and ask any questions.

The two primary breaking changes that 5.0.0 includes are:

  • Reduce disk space with CouchDB Nouveau
  • Hide the upgrade button in the admin app for k8s deployments

Let’s dive into what each of these does and why it’s a breaking change.

Reduce disk space with CouchDB Nouveau

For some time now, the Hosting Total Cost of Ownership (TCO) squad has been focusing on reducing TCO by decreasing the total amount of disk space the CHT takes. Early testing shows this feature is capable of reducing total disk savings by up to 30% in larger deployments. More details will be shared about this technical improvement as we approach its release.

The feature requires a new service to run alongside CouchDB, called Nouveau. Deployments using Docker can use in-app upgrades seamlessly. However, Kubernetes-based deployments will have to update their helm charts and redeploy. The fact that a new service is being deployed and that Kubernetes users cannot use the in-app upgrade process makes it a breaking change.

We will publish explicit, step-by-step documentation to make upgrades straightforward for Kubernetes users. Early adopters are welcome to check out the ticket or ask questions below for information about how to deploy alpha versions of this code. It is feature complete and ready for testing!

Hide the upgrade button in the admin app for k8s deployments

One issue that we’ve seen large Kubernetes deployments suffer from is that the in-app upgrade process is used and then, at a later date, the helm chart gets accidentally re-run against production. This causes the data in the CHT to be on a newer version than the CHT software that is running. To avoid this, we will remove the in-app ability to upgrade in Kubernetes deployments. After this change, Kubernetes upgrades will need to first stage the upgrade in the admin app, wait for the view indexing to finish and finally upgrade via helm charts.

As this improvement removes a feature from the CHT, it is considered a breaking change.

5.0.0 Schedule

The timeline for releasing 5.0.0 is before the end of 2025, possibly as soon as early in Q3. The milestone is still being worked on, and any contribution or support is most welcome.

Meanwhile, two new significant features (SSO and Task Prioritization) will be released before 5.0.0, in a 4.x release, so stay tuned!

8 Likes

Because 5.x is already getting meaty with updates that are under risk of becoming stale and are already hard to keep up to date, we have decided to start merging 5.x work into the master branch.

Prior to doing this, we will create a 4.x branch, which will receive all pending work that is on the course of being developed and delivered for 4.x. We will release a future 4.22.0 from this branch. Any bugs or additional work that needs to be published in a 4.x release will be merged into this new 4.x branch along with master. We will add the same branch protection rules to the 4.x branch as on master to insure it is stable.
This means that every contribution to 4.x will need two PRs - one merged into 4.x and one merged into master. This can be a bit of a hassle, but we will make an effort to make this interim period as short as possible.

1 Like

Hi again!

Please note that today is the day that a two 5.0 features were merged to master . Per above, this means you may need to submit two PRs as needed.

As well, please note that you should update your development environment too.

1 Like

@jkuester or @diana - what is the name of the 4.x branch we should be targeting for PRs in addition to the PR for master? I’d have expected to see a 4.x one created in the last day or two, but don’t see it. Thanks!

git reflog --date=local --all|grep "4\.2"      
8abb72c6b HEAD@{Fri Aug 22 21:14:16 2025}: checkout: moving from run-api-as-node-4.2x to master
ad2507e92 refs/remotes/origin/run-api-as-node-4.2x@{Fri Aug 22 20:46:54 2025}: update by push
ad2507e92 refs/heads/run-api-as-node-4.2x@{Fri Aug 22 20:46:48 2025}: branch: Created from HEAD
ad2507e92 HEAD@{Fri Aug 22 20:46:48 2025}: checkout: moving from run-api-as-node to run-api-as-node-4.2x
8b1651193 refs/remotes/origin/4.21.x-sync-interval-30@{Thu Aug 7 15:31:06 2025}: fetch: storing head
7197a46c1 refs/remotes/origin/4.20.x@{Tue Jul 29 21:37:29 2025}: fetch: fast-forward
f02285311 refs/remotes/origin/4.21.x@{Tue Jul 29 21:37:29 2025}: fetch: fast-forward
a9f0ca707 refs/remotes/origin/4.20.x@{Mon Jul 21 13:19:25 2025}: fetch: storing head
97d9b4834 refs/remotes/origin/4.20.x-scalability@{Mon Jul 21 13:19:25 2025}: fetch: storing head
f4e54b43f refs/remotes/origin/4.21.x@{Mon Jul 21 13:19:25 2025}: fetch: storing head

And actually, while I’m here, I’d love some tips on how to manage my code here for targeting the two branches. I got CI to pass on a PR I’m working on and then saw that GH offered a “Merge Master to this branch?” button. I clicked it, not thinking that now the branch is invalid for merging into the 4.x branch as it now has all of master in it.

I think I need to cut a clean branch off of the 4.x branch and then cherry pick just my commits for my PR into this new branch, excluding any of the new 5.x code commits - is that right? Then have that branch target the 4.x branch in the PR?

Thanks x2!

Hi team!

I’ve just created a 4.x branch that will be used as a stable source for future 4.x releases. This branch has the same protection rules as master. If you have an open PR against master that should be released in a 4.x release, please open a second PR against the 4.x branch.

1 Like

If folks are interested in trying out this upcoming version, they can test on a clone of their production instance or on a local development instance.

Login as an administrator and go to admin section. From there, go to upgrades, and into pre-relases and choose “Master (~5.0.0)”.

2 Likes