On the subject of Ubuntu Touch versioning scheme
-
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.
-
-
@peat_psuwit said in On the subject of Ubuntu Touch versioning scheme:
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.
Could you please elaborate why this type of version scheme makes it harder to introduce larger changes? We could always have OTA-x.y if needed for smaller changes in-between (and in practice already done so when specific issues/devices needed hotfixes), but I wonder what is the issue for larger ones?
Otherwise, I don't have a strong opinion on this. Keeping the current versioning scheme or doing Ubuntu Touch 24.0.x.y both seem fine to me.
To a developer, being able to recognize the Ubuntu base from the version feels beneficial, but I can also see why complete decoupling was considered before, especially when we were lagging behind too much, like with 16.04 or now with 20.04)
-
I would go with option 2 and use 2404 and that way somewhat keep the versioning scheme from Canonical.
-
as a user, I dont care about version that much,
but as a advanced user, second Option seems to be best, since i know what is current LTS Ubuntu and therefore I want to have its latest version on mine phone -
I would like to propose option 2 but keeping the "." between year and month
so if the next version is released in may 2025 it would be called 25.05.0
this has all the benefits of opton 2, feature releases and bugfix releases included while not distancing ourselves from the broader ubuntu community any more than we already have (identity wise)
i think we can work around the confusion with the Ubuntu version we're based on by utilizing code names in the release announcement similar to upstream ubuntu
e.g. Ubuntu 24.04 Noble Numbat vs Ubuntu Touch 25.03.0 Marvelous Moon
the benefit of the scheme is that is easy to see when the version was released while keeping a distinction clear between feature and bug-fix release. keeps the version short and memorable while
paying homage to the broader community -
@peat_psuwit Options 1 or 3 are equally good
-
Option 3 seems to be the best option to me but perhaps tweak it a bit to avoid confusion with Ubuntu's point releases. We can even put the whole Ubuntu version with point release and add our own version at the end? A bit too long but would be clear and less confusion.
-
@TheKit said in On the subject of Ubuntu Touch versioning scheme:
Could you please elaborate why this type of version scheme makes it harder to introduce larger changes? We could always have OTA-x.y if needed for smaller changes in-between (and in practice already done so when specific issues/devices needed hotfixes), but I wonder what is the issue for larger ones?
A special consideration is needed in order to isolate changes in-pipeline from hotfixes. For example, suppose we've landed multi-component code which improves Wayland application support but require some more testing (the larger change). But then there's a severe vulnerability in QtWebEngine which we have to patch as soon as possible. The original 20.04 OTA-x scheme doesn't have a way to do that; we would have to wait until the change is tested before we can release the next OTA.
One way to alleviate that is to take a procedure from Canonical days and take an Apt snapshot at the OTA release time (nowadays trivially doable using Aptly), then binary-copy the QWE package from the current devel archive to the snapshot archive and build an rootfs image from that.
Or am I understanding your question wrong?
@Fuseteam said in On the subject of Ubuntu Touch versioning scheme:
I would like to propose option 2 but keeping the "." between year and month
so if the next version is released in may 2025 it would be called 25.05.0
[...]
i think we can work around the confusion with the Ubuntu version we're based on by utilizing code names in the release announcement similar to upstream ubuntu
e.g. Ubuntu 24.04 Noble Numbat vs Ubuntu Touch 25.03.0 Marvelous Moon
I'm not sure that could really workaround the confusion though. For example, suppose we have a release in April 2026 then the version number would be e.g. Ubuntu Touch 26.04.0 Callisto [1]. But then we're likely not quite ready to base our system on Ubuntu 26.04 I think that unless we carry our codename everywhere (impractical, IMHO), I think confusions will ensue.
[1]: someone suggested using moons in solar system as a codename in the UBports development channel.
