Version arm64 0.97 tar containing verson 0.96?

[tucoawa]

Description

As the title suggests, extracting the latest tar a version 0.96 pops up :) Thanks a lot for everything!

TriliumNext Version

0.97

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

Linux

Error logs

No response

[dosubot]

It looks like the arm64 tarball labeled as version 0.97 actually contains version 0.96. This likely happened because the version in package.json wasn't updated to 0.97 before the arm64 build started, so the old version got packaged instead. There's no sign this has affected other architectures, but it's a good idea to check the x64 tarball to confirm.

If you need 0.97 specifically, you can either wait for a corrected release or build from source after verifying the version bump. This kind of issue can be avoided in the future by ensuring the version is updated before any build jobs run.
You can see how the build process pulls the version directly from package.json at build time here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[eliandoran]

@tucoawa , @dosu is only partially right in the sense that we got the wrong version number. This might cause some caching issues, so I've triggered a rebuild with the corrected one.

[dosubot]

Thanks for clarifying the situation and for triggering the rebuild. I couldn't find any official documentation or threads with guidance for users on handling caching issues after a rebuild or corrected release, so there aren't any specific user steps recommended at this time. If you need help checking the status of the corrected build or run into any further issues, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[eliandoran]

@dosu, for further reference: Trilium Desktop makes heavy use of caching by setting a very large lifetime for any resources. The resources are prefixed by the version number.

In this case a release with the same version is problematic since you can have new files from the new version combined with the cached files of the previous version, usually resulting in quite unexpected issues.

To bypass this, a full cache reset is necessary. More specifically, Ctrl+Shift+I to open "Inspect Element" -> go to Networking tab -> check "Bypass cache" and Ctrl+R to refresh.

[dosubot]

That's exactly right—Trilium Desktop serves static resources (like scripts and stylesheets) under URLs that include the app version, and sets a long cache lifetime for these files. This version prefix is the main cache-busting mechanism: when the version changes, the resource URLs change, so browsers fetch fresh files. But if a release is rebuilt with the same version number, you can end up with a mix of old and new files from cache, which causes unpredictable issues.

In these cases, a full cache reset is necessary. The steps you described—open Developer Tools with Ctrl+Shift+I, go to the Network tab, check "Bypass cache", and refresh with Ctrl+R—are the recommended way to force a reload of all resources and avoid these problems. There’s no additional built-in or automated cache-busting beyond this process in Trilium Desktop’s codebase. For reference, you can see how the version prefix and cache headers are implemented in the server code here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}