github liketrek/TREK v5.0.0-pre.1

pre-release6 hours ago

⚠ PRE-RELEASE: USE AT YOUR OWN RISK ⚠

This is a pre-release build of TREK. It may contain bugs, incomplete features, or breaking changes. It is not recommended for production use.

  • Do not use this on a live instance without a full backup
  • Database migrations may not be reversible
  • APIs and configuration options are subject to change without notice

If you encounter issues, please report them at https://github.com/liketrek/TREK/issues.

Stable releases are available on the main release page.

⚠ Pre-release image, not recommended for production use. latest and 4 stay on 4.3.3.

Tag Description
5.0.0-pre.1 Pinned to this exact pre-release build
5-pre Latest pre-release on the v5 line
latest-pre Latest pre-release across all versions
docker pull mauriceboe/trek:5.0.0-pre.1

First pre-release on the way to 5.0.0, and the largest release since TREK started: 877 commits and close to 6,900 changed files since 4.3.3. The full list of what changed lives in the release PR, #2499. A few of the bigger pieces: a help center on every screen, four new languages, the redesigned desktop trip page, settings and admin, the Tours addon, Web Push notifications, receipt scanning, a much more complete offline mode, and a long list of fixes around data safety, sign-in, reminders and the planner.

The big one: MikroORM

The server reads and writes its database through MikroORM entities, repositories and transactions, and an existing install is picked up from its current schema version on the first start, with nothing to do by hand. (#2416)

This touches nearly every part of TREK that stores something, which is why we need this pre-release tested on real data more than any before it. What happens on the first start:

  • TREK writes a copy of your database next to it before it changes anything, named pre-migrate-legacy-244-<time>.db for a 4.3.3 install. Make sure data/ has free space of roughly the size of travel.db; if the copy cannot be written, TREK refuses to start and migrates nothing.
  • The migration then runs in one transaction. If it fails, nothing is recorded and the next start tries again.
  • Installs older than 4.3.3, back to 3.x, take the same path.

How to test it

The most helpful thing you can do is run this pre-release against a copy of your real production data. Test data rarely has the history a database collects over months of use, and that history is exactly what the migration has to get right. How you test is of course up to you, but this is what we recommend:

  • Leave your live instance on 4.3.3.
  • Stop it for a moment, copy the data and uploads folders, and start it again.
  • Start a second container with mauriceboe/trek:5.0.0-pre.1 on the copies, on another port. If you set ENCRYPTION_KEY, use the same value.
  • The copy runs the same scheduled jobs as your live instance, so it can send trip reminders and notifications a second time. Turn off email and Web Push in the copy's admin settings if that would bother your users.
  • SSO on the copy needs its own redirect URL at your identity provider, or sign in with a password.

We do not recommend upgrading your live instance with this pre-release. If you do it anyway, take a full backup of data and uploads first. There is no supported way back: 4.3.3 starts on a database that 5.0.0 has migrated without any warning, but it runs on a schema it only partly understands. The only clean way back is to stop TREK, delete travel.db-wal and travel.db-shm, put the pre-migrate-legacy-244-*.db copy (or your own backup) in place of travel.db, and start 4.3.3 again. Everything created under 5.0.0 is lost then.

Before you start it

  • Encryption key: an ENCRYPTION_KEY that differs from data/.encryption_key now stops the start with a message, instead of silently replacing the stored key. Set the variable back to the stored value, remove it, or run the rotation script first.
  • Helm: with generateEncryptionKey: true under helm template, Argo CD or Flux, the chart renders a new key on every run, and TREK now refuses to start on it. Use existingSecret there. Readiness now uses /api/health/ready, and a startup probe was added.
  • Plugins: a plugin whose manifest only allows TREK 4.x is switched off on the first start. We have asked plugin authors to update their ranges; TREK_PLUGINS_IGNORE_TREK_RANGE=true turns the refusal into a warning. Plugin SQL now has a 2 second time limit per query.
  • Configuration: no environment variable was removed or renamed.

Feedback

This is where we need you most. Feedback on all changes helps, on stability and on whether every feature is still there. But the ORM part is the one we are most worried about, and the one that benefits most from being run on databases we do not have. When you report, please tell us:

  • which version you upgraded from, and whether the first start went through (the lines starting with [DB] in the log)
  • what broke, with steps to reproduce

Parts worth clicking through once on your copy:

  • creating a backup and restoring it
  • costs: splits, payers who left the trip, settle-up, expenses saved offline
  • bookings with a price or linked costs, the booking import, moving bookings within a day, stays
  • changing trip dates and copying a trip
  • journeys with photos and share links
  • signing in: email with mixed case, SSO, passkeys, logging out other devices
  • plugins, MCP, and the smaller addons: packing, to-do, Collab, Vacay, Atlas, Collections, Immich and Synology

Bug reports at https://github.com/liketrek/TREK/issues, with 5.0.0-pre.1 in the title.

Full Changelog: v4.3.3...v5.0.0-pre.1

Don't miss a new TREK release

NewReleases is sending notifications on new releases.