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.
-
In the Board of Trustees meeting on 4th February, I've brought the release version numbering up as a discussion topic. The attendees considered the comments on this post and have agreed that it's important to still reference Ubuntu version in our versioning scheme, while it would be beneficial development-wise to have a major-minor release system in place.
As such, we've come up with a versioning scheme of "Ubuntu Touch [Ubuntu version]-[release version]" (a variant of option 3). For example, the next version of Ubuntu Touch would be referred to as "Ubuntu Touch 24.04-1.0".
We believe this versioning scheme is both understandable and practical.
-
I realize this was already decided but I still think it is important to address. I think the selected scheme will cause marketing issues for the project. 24.04-1.0 means the first 60% of the version number will give a lot of confusing messaging. The following are just things I thought of immediately so there could be other potential issues.
- it suggests to users that changes happen rarely
- suggests updates are minor because the first 60% doesn't change most of the time
- for those who know the numbers mean year.month could suggest that they found an older version.
All of the flavours and remixes that keep up with Ubuntu releases make sense to use the standard Ubuntu scheme but since Ubuntu Touch is more of a remix based on LTS it would be better to have a separate scheme. Linux Mint, Zorin OS, and others have a different style based on the amount of versions they have made overall with the second number indicating the amount of releases during the LTS period. Linux Mint 22.1 is the second release of 22.x but first follow up release. Zorin does a very similar thing.
I think Ubuntu Touch would be served better by an independent scheme because most people dont care which LTS a distro is based on as long as it works but version numbers are a form of marketing opportunity so they cant be ignored just because most people dont care. If Linux Mint or Zorin OS released with the same version scheme of 24.04 (or with these additional numbers) that Ubuntu uses anywhere between 6 months to 1 year after Ubuntu it would look old.
Zorin OS is not seen as old when they released their latest version of 17.2 and yet Zorin OS 17.2 is based on Ubuntu 22.04.
I recommend one of the following:
- 31.x
- 31 = major number based on the LTS, only updates every LTS upgrade
- .x = overall releases of that branch
- so OTA-6 would be 31.6
- 25.6
- 25 = year it was released in
- .6 = month it was released in
- 25.6.2 would be the normal scheme with maintenance fixes
- 30
- 30 = major releases regardless of the LTS saying that 30 and 31 and so on could all be based on the same LTS.
- 30.1 = true minor releases similar to GNOME style
I personally prefer #1 but #2 & #3 would also be good I think. Just my two cents.
-
@peat_psuwit said in On the subject of Ubuntu Touch versioning scheme:
In the Board of Trustees meeting on 4th February, I've brought the release version numbering up as a discussion topic. The attendees considered the comments on this post and have agreed that it's important to still reference Ubuntu version in our versioning scheme, while it would be beneficial development-wise to have a major-minor release system in place.
As such, we've come up with a versioning scheme of "Ubuntu Touch [Ubuntu version]-[release version]" (a variant of option 3). For example, the next version of Ubuntu Touch would be referred to as "Ubuntu Touch 24.04-1.0".
We believe this versioning scheme is both understandable and practical.
I know I'm too late to the party; but if you're already staying this close to the current naming scheme why not go all the way to 24.04 OTA-1.0? Everyone is familiar with that naming convention already, and introducing a minor version number is "backwards" compatible by calling every previous OTA-x.0 if needed. And soon when UT reaches version parity with ubuntu 24.04 the colloquial OTA-x(.y) will be back in action offering an easy shortcut to identify the current release.
Aka I'm getting old and grumpy, but I really can't stand the relentless reshuffling of naming schemes that usually offer no improvement and just increase the mental load on trying to figure out wtf is going on again
