Update discourse to latest(ish) ESR version from previous, soon-to-be unsupported, ESR version.
Upstream changes: https://releases.discourse.org/changelog/custom?end=v2026.7.0&start=v2026.1.4
Changes:
- simple version / dep updates of all plugins and discourse itself
- updated the update script to correctly handle changes to discourses's architecture, and fixed a bug
- the NamedTemporaryFiles were not flush()ed, which meant their content was not written
- discourse now has dependencies under `migrations/` which are specified by path. this requires downloading the `migrations/` directory during the update so `bundle lock` / `bundix` run successfully. the logic for performing this was borrowed from the gitlab package.
- the hashes for the newly added dart-sass download are automatically updated
- updated some patches to match changes in the targeted code (notification_email, prebuild-asset-processor)
- delete a no longer relevant patch (unicorn_logging_and_timeout) (discourse no longer uses unicorn internally, although the external interface is similar / pretends to still exist)
- added two new patches, safe-exec-from-nix-store and sass_embedded_vendored_dart_sass
- safe-exec-from-nix-store: add /nix/store to the list of executable paths for the container used to sandbox imagemagick, which by default only contains the standard FHS paths
- sass_embedded_vendored_dart_sass: patch sass-embedded to use a version of dart-sass provided by the package instead of downloading it's own which would fail. this patch also involves code in default.nix which sets DART_SASS_VENDORED to the path of a downloaded dart-sass version
- updated the comment on prebuild-asset-processor.patch to more accurately reflect what and why it exists
3.5.x will be EOL by the end of January 2026. 2025.12.0 is the newest
released version. Ref: https://releases.discourse.org/
libv8-node is not compatible with NodeJS 24 in this version.
The plugin updater would previously stumble over compat spec version
entries that begin with angled brackets.
````
< 3.3.0.beta1-dev: 56b0de3896361b6a87523537c8f5b450d2fe0807
3.2.0: 33c43ca51ac7b7baa8a309a269dcf8685b8bd638
< 3.2.0.beta2-dev: ac930c509e2a5b0c37b84bcea28d332e686add95
3.1.999: a304cd2028ccf1f5b00f5137633aa7027a1fd334
3.1.0.beta3: 9c270cac9abc1c2b30574d8c655fb3a90546236b
[...]
````
The update.py script would error out if the spec had a trailing new
line. The split that follows it would try to split it into two, and
error out as it can't.
...in the update script and remove it from the Gemfile.lock. Having
it there causes a failure with the error message:
Could not find libv8-node-16.10.0.0-aarch64-linux in any of the
sources (Bundler::GemNotFound)
And since we're not using the prebuilt binary packages anyway, we
don't need it there in the first place.
Add a DiscourseVersion class which handles Discourse's version
numbering properly when sorting - beta versions are sorted lower than
their respective release versions. It can also return both its version
number and equivalent git tag, removing the need for `rev2version` and
manually adding `v` to the front.
Using DiscourseVersion instead of LooseVersion, we can list all
current version number tags from the `discourse` repo and sort them
correctly, giving us the latest one, regardless of type; i.e. we don't
have to filter for only release versions or beta versions anymore.
This also implements the plugin pinning algorithm laid out here:
https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971
to make sure we don't upgrade plugins further than what's compatible
with our currently packaged Discourse version. While it likely won't
matter much most of the time if we continue packaging the beta
versions, it could be helpful if we decide to go back to packaging
release versions or if we run into issues with future upgrades. In
that case, the plugins could still be updated safely even though we're
not on the latest version of Discourse.
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
Let the update.py script handle the initial, repetitive task of
packaging new plugins. With this in place, the plugin only needs to be
added to the list in `update-plugins` and most of the work will be
done automatically when the script is run. Metadata still needs to be
filled in manually and some packages may of course require additional
work/patching.
