Since the UBports Foundation inherited the Ubuntu Touch project from Canonical Ltd., we've always been using the semi-rolling release model. We would have a stable (LTS) Ubuntu release, and then we continuously build the Ubuntu Touch-specific code on top. As we attempted to move our base to Ubuntu 20.04, a few problems have been discovered:

Because Ubuntu 20.04 is a quite different base OS for us compared to Ubuntu 16.04, a number of components had to be changed in order to accommodate this, and they often weren't compatible with the 16.04 base. This meant diverging code between these two bases. This created a confusion as to which code base or branch does a piece of code need to land. In particular, since we're still being perceived as a rolling release distribution, contributors sometimes expect their changes to appear in the next immediate update, rather than together with upcoming base OS change. This creates confusion as whether a change will come to them in the base upgrade or not.
Since we don't roll-out OS changes via individual packages, when a bug fix, or worse, a security fix needs to be released, they can't be released without releasing all the other changes that have landed in our code base. The sum of all code changes, however, might not be ready for prime time, yet. This creates a delay between when a bug gets fixed and when the fix reaches the end users.
Also, when it's time to release an update to the end users, we usually have to pause the development ("freeze") to allow us to publish bug fixes of the update without introducing additional new code which might be subject to more issues.

With the upcoming Ubuntu 24.04 base OS upgrade, we take this opportunity to make a change in our release model: We plan to switch to the fixed-release model.With the upgrade to Ubuntu 24.04, the release model will be as follows:

Each release of Ubuntu Touch will use the format of `<year>.<month>.<minor>`, where `<year>` and `<month>` are the expected year and month of the release.
The feature releases will start with the `<minor>` version of `0`. These releases can contain new features, major changes etc. For example, the first release to use Ubuntu 24.04 as base will (probably) use the version 24.6.0. We plan to have a feature release every 6 months.
After that, each point release will increment the `<minor>` version by `1`. The releases will contain only security patches, bug fixes or small changes [1], as well as updates from the base Ubuntu version. We plan to have a minor release every 2 months.
We will support each feature release for approximately 1 month after the next feature release is released (i.e. we will have 1 more update, aka point release). As a community effort, we will only be able to support at most 2 feature releases in parallel. (This may change, if Ubuntu Touch maintenance becomes supported e.g. by phone vendors, taking over funding maintenance of more feature releases in parallel).

[1] For imported packages, the patch (and in some cases minor) version updates are allowed.To accommodate this change, we will also change how we organize branches in our Git repositories, and also how our CI will build these branches.

The `main` branch (or the `ubports/latest` branch for packaging Git repos) will continue to represent the latest development code, and will form a part of the next feature release of Ubuntu Touch. CI will build the code in this repository into the development APT archive.
 The `ubports/<UT release>` branches (e.g. `ubports/24.6.x`) will represent the code that will become the named feature release and its minor releases. CI will build the code in this repository into the APT repository for the named release. These `ubports/<UT release>` will be created as part of the feature release process.
The `ubports/<Ubuntu release>` branches (e.g. `ubports/noble`) will no longer exist. This used to represent the code which is built on top of a particular Ubuntu release, but has been the source of confusion in the past.
Any other branches (e.g. `personal/<username>/*` or any other branches) will not be built automatically (any more). The code will be built by the CI when an MR targeting the aforementioned branches is created.
The `ubports/<Ubuntu release>_-_<extension>` scheme will be no longer supported, either. We will provide another way for testing cross-repository changes in the form of explicit dependency declarations.

In most cases, an MR should target the `main` branch (or the `ubports/latest` branch). If a change is desirable to backport to the next minor release of (one of) the previous feature release(s), we (in most cases: the reviewer of an MR) will then cherry-pick or backport such changes to `ubports/<UT release>` branches. An exception is when a change is no longer applicable to the `main` branch (e.g. due to such code being removed). In such case, it's allowed to create an MR targeting `ubports/<UT release>` branches.With the release of Ubuntu Touch 20.04 OTA-4 the core developers considered Ubuntu Touch based on Ubuntu 20.04 LTS as stable and from then on they would only fix severe issues / security problems in Ubuntu Touch focal. We plan to release OTA-5, OTA-6, etc. for Ubuntu Touch based on 20.04 until we're ready with the Ubuntu 24.04 base OS change, but these won't bring invasive changes nor shiny new features; the upcoming 20.04 OTAs will provide you with security support and pressing bug solutions that can't wait until the initial release of Ubuntu Touch 24.6.x.

From the development perspective, we will treat the last OTA as a feature release, and classify `ubports/focal` as a release branch. We will create a `ubports/focal` branch on every Git repository maintained by us, to signify that from now on, the `main` branch (and `ubports/latest` branch for packaging Git repos) will be used for the development of 24.6.0. When this is complete, new commits (both features and bug fixes) will land on the `main` branch (`ubports/latest` branch resp.) first, and then be backported to the `ubports/focal` branch when appropriate.