Change of change of plan - sorry for any confusion!

We've decided that TLXOS 4.x is no longer suitable as a Long Term Stable
(LTS) release - particularly in the SFF and RePC cases - due to it being forever
limited to at most a 5.4 Linux kernel, on account of rigid sizing of /boot.
The 5.4 kernel is too old to support the latest hardware, and kernel developers
are no longer bothering to backport support for new hardware to it (on account
of it now being two longterm releases out of date).

Consequently we now intend to release TLXOS 5.0.0 as a new LTS baseline,
this being more-or-less a continuation of TLXOS 4.11.x with a layout change,
i.e.  still based on Debian 10 (Buster).  At the same time, we'll release TLXOS
5.1.0 as a new progressive release, based on Debian 11 (Bullseye).

So we've reneged on our earlier promise that TLXOS 5.x will be exclusively
Bullseye-based, but everything else remains mostly as previously advised.
Upgrading from TLXOS 4.x to 5.x will not require TMS v9, and support for the
new firmware format will be added later.

- TLXOS 5.0.0 will - if possible - include a more recent kernel that still
  supports Reiser4, e.g. 5.15.  TLXOS 5.1.0 will include a significantly more
  recent kernel, e.g. 6.1, and will probably revert to use of an uncompressed
  Ext2 root filesystem, on account of the current lack of a Reiser4 patch for
  6.1 (and also because compression is no longer needed in order to fit within
  rigid TLXOS 4.x sizing).

- TLXOS will no longer have a separate Maintenance Mode partition (or Linux
  kernel).  Maintenance Mode will be merged into the /boot filesystem, as an
  alternative initramfs that will use the same kernel as Normal Mode.

- TLXOS installation will become more flexible with regard to filesystem sizes.
  Upgrades will be able to enlarge the base root filesystem (/actualroot) as
  needed, and if necessary will repartition to enlarge /boot also, although
  that would necessarily result in loss of midlayer (/config) data, i.e. reset
  to default settings.

- TLXOS 5.0.x will still support 32-bit-only Raspberry Pi models (v1, original
  Pi Zero, and Pi 2 v1.1) and 32-bit-only PCs, but TLXOS 5.1.0 and later will
  not.  TLXOS RePC 5.1.0 and later will be fully 64-bit only, and TLXOS SFF
  will be discontinued after 5.0.x; a means to transition from SFF (NUC32 /
  NUC64) to RePC will be provided.  TLXOS RPi IoT will be discontinued after
  5.0.x also, and TLXOS RPi 5.1.0 and later will use a 64-bit Pi kernel with a
  32-bit userspace, which will not run on the Pi 2 (except for the Pi 2 v1.2, a
  rare model) or CM2.

We still intend to achieve the TMS 4.x-5.0 transition by means of a TLXOS 4.x
update with a TLXOS 5.x-compatible Maintenance Mode image that, when
booted, will apply an irreversible TLXOS 5.x layout conversion, i.e. it will
merge the Boot and Maintenance Mode partitions.  This will put your devices in
a kind of "version 4.99" state, from which you can upgrade to 5.x, but not
downgrade.

We will probably implement the following formerly-TMS9-likely features prior to
TMS 9.0.0:

- TLXOS licenses will be consolidated into a one-license-fits-all solution,
  i.e. you will be able to run any edition of TLXOS using a common entitlement.
  New licenses will be at the higher SFF/RePC cost (USD $15 per device); we
  will not retroactively compensate SFF/RePC owners with additional
  entitlements.

- Improved VPN capabilities, including password-based OpenVPN and
  Wireguard.

The following features currently remain deferred until TMS 9.0.0:

- Encryption of updates (TLXOS firmware, tms_client, hotfixes) will be
  removed, and the firmware format will be simplified to be a zip file
  containing binary firmware object(s) and metadata file(s) in a format that
  ThinLinX will publicly document, along with optional GPG signature(s).  This
  will allow customers to create their own hotfixes.  TMS will check GPG
  signatures against an approved keyring and report whether or not the update
  passes signature checks.

- Upgrade of boot[/TFM] and root filesystems will be completely separate,
  allowing upgrade to a newer Linux kernel (and Maintenance Mode image)
  while remaining at the same base firmware version.

- Rewrite of TMS for internal client-server separation and multi-session
  capability, i.e. an "always on" background service/daemon component and one
  or more on-demand GUIs.  TMS was not designed for this, so it is a very
  extensive and ambitious rewrite.  TMS GUIs will be able to run on a different
  host than the service/daemon, and you will be be able to run two or more
  concurrently.

- TMS 9.0.0 will introduce the concept of a "filestore" database, whereby
  downloaded updates, and files installed by the user, will be permanently
  stored in a hash tree such that clients can request download of such objects
  by hash rather than by name.  This means that files installed using TMS'
  "File->Install File" option (e.g. SSH keys and CA certs) will be part of a
  saved profile, and client devices will automatically download these if they
  are missing.