Hello. I'm Ratchanan Srirattanamet, a member of Ubuntu Touch core developer team. We need your opinion on how we version the next version of Ubuntu Touch.
Early last year, we - the core developer team - had a discussion on how we can improve our release pipelines. One of the results that came out of it was that we want to de-couple our versioning scheme from Ubuntu LTS version we use as our base, to give us flexibility when doing a large-scale feature release independently of Ubuntu releases. This lead to our announcement in February 2024 announcing the intention to change.
However, as we sort out technical challenges to get the changes we announced implemented, one of our community members voiced a concern that, by using our own versioning scheme, we might distance ourselves from the broader Ubuntu community even more than we already have. And it also hits me that versioning scheme is the matter of project identity.
Fortunately (or unfortunately), at this point nothing is really set in stone yet. So we still can change up how we do versioning.
We have a few options:
Option 1: Keep the current versioning scheme
The current versioning scheme (20.04 OTA-x) comes from the necessity that we needed to provide parallel support for Ubuntu 16.04-based OTAs at the same time as we developed our Ubuntu 20.04-based OTAs. We could keep this versioning scheme, which will essentially make us continue to use rolling-release scheme with more-or-less the same way we have been operating.
This 20.04 OTA-x, 24.04 OTA-x, etc. version scheme makes it clear which version of Ubuntu we're based on. However, this will make it harder for us to introduce larger, system-wide changes which takes time to develop and require more comprehensive testing. It also make it harder to offer hotfixes in between OTA releases when changes in the pipeline might not be ready for shipment yet.
Option 2: Complete decouple of Ubuntu version
On the opposite side there is a scheme similar to the announcement we mentioned above. The current revision we have after a few discussions is to drop the "." between year and month to avoid confusion with the Ubuntu version we're based on. For example, if the next major release of Ubuntu Touch was planned to be released in May 2025, we would then call this release "2505.0".
Between major releases, we'll backport bug fixes, security updates, and small improvements, providing them as minor point releases of the previous major release (e.g. 2505.1, 2505.2, etc.). This scheme makes it more clear which of the updates are feature updates vs. bugfixes, and allows us to publish security fixes and important bugfixes more frequently, with less testing effort and shorter development freeze phases.
To implement this scheme, the following changes have been/will be implemented:
-
When we started working on Ubuntu Touch 24.04, we introduced ubports/focal Git branches across all code compenents' Git repositories. This allows us to bring individual code changes to the next 20.04 OTA-x while all the development for the next UT based on Ubuntu 24.04 LTS happens on the main branches of the Git repositories. With this move, we detached developed of the next major version of Ubuntu Touch from preparation of the next stable 20.04 OTA-x release.
-
With this split branching in place, we added a development policy: a code change can only land in the next UT stable release (i.e. next 20.04 OTA-x, i.e. on the component's ubports/focal Git branch), if it has been accepted for the next major release (i.e. on the component's main branch). This protects us from issues being fixed for UT 20.04 while still unfixed for the next major UT release.
-
The next policy we chose to constrain ourselves with: no invasive changes for UT 20.04 OTA-x release. Once a major release has been published, our goal is to stabilize and consolidate it more and more. New features these days only get accepted on components' main branches, i.e. they can only become a feature of the next major release of UT.
However, as I mentioned earlier, this will unfortunately mean Ubuntu Touch will be more "on its own" in comparison to the rest of the Ubuntu ecosystem & community. It would be harder for us if, in the future, we would like to become an Ubuntu flavor again.
Option 3: Incorporate Ubuntu version in the versioning scheme, but adapt it for major release scheme
A sort-of middle ground between these 2 schemes is to still use Ubuntu version in our version, but then add a suffix to the version to distinguish each of our major release. For example, the next Ubuntu Touch version could be called "Ubuntu Touch 24.04.0" to indicate that this is the first major release of Ubuntu Touch based on Ubuntu 24.04. Then, the next major version could be called "Ubuntu Touch 24.04.1", "Ubuntu Touch 24.04.2" and so on. To be clear, we want to tie into only the major version numbers of Ubuntu e.g. 24.04, and not any of its point releases.
For minor releases, we could call it something like "Ubuntu Touch 24.04.0.1", or we could borrow a convention from OpenSSH and do something like "Ubuntu Touch 24.04.0p1".
This scheme could give benefit of both worlds, allowing distinction on major releases vs. minor releases while still having a tie with Ubuntu version we use. However, there's a large potential that our versioning will get confused with Ubuntu's point releases. If we want to go this route, we might have to choose a better suffix to make a relationship between Ubuntu version and our version clearer.
Option 4: Complete rolling-release; call it OTA-x at all time
For completeness, it might be worth mentioning that Ubuntu Touch has not always been referred to by its Ubuntu version. Both in the Canonical time and after UBports initially adopt the project, Ubuntu Touch updates were referred to simply as "OTA-n" without regards to base Ubuntu version. Even when UBports had its first-ever Ubuntu base upgrade, it was called simply OTA-4, not 16.04 OTA-1.
However, I believe this would give the worst of both worlds: decoupling from Ubuntu version while stucking with rolling-release scheme with all its limitation and risks regarding software stability.
I believe it's important for our community to have a say in this matter. We appreciate all feedback and suggestions, including suggestions of the new scheme not on the list above. Thank you.
