Hi,
Can we please have the following tracks created for snaps managed by the Ubuntu Desktop team:
Thank you
Hi!
Per Process for aliases, auto-connections and tracks 2, we need a voting/discussion period for snaps that do not have tracks already.
I created the new tracks for the snap-store snap, but I have some questions regarding the rest of the snaps. Before we give a snap tracks we like to have a bit more info. If you would be able to provide answers to the following questions for the above snaps, that would be very helpful!
Please let me know!
Thanks
Emma
Hi Emma,
All of the snaps in question are developed at Canonical and part of the Ubuntu release itself. In terms of release cadence for the snap-store, firmware-updater, desktop-security-center and prompting-client we would be making a major version change only when adding functionality that is not going to be backported to prior LTS releases of Ubuntu. For ubuntu-desktop-bootstrap and factory-reset-tools we want to create a new track for each Ubuntu release. Support for old versions will be in-line with standard LTS support and new versions will most likely have some backwards incompatibility but largely from interactions with other components in the OS rather than breaking changes to config and local data. For example, the installer (ubuntu-desktop-bootstrap) is very tightly coupled to the Ubuntu release it is installing.
We are working with the Foundations team to sort out seeding these specific tracks in the 24.04.1 and 24.10 releases so we ideally need them in place as soon as possible. Sorry for the late notice on this, we were not aware that creating new tracks could not be done through the snapcraft.io dashboard!
Thanks,
Innes
Should these new tracks instead be named YY.MM (ie corresponding to the Ubuntu releases) rather then 1 and 2 - how does a user know which is the most appropriate track for them otherwise?
Also if these are planned to be seeded then ideally the tracks would follow the guidance set out in [Technical Board] Feedback requested: draft policy on third party software sources included by Ubuntu - Foundations - Ubuntu Community Hub - ie. even if you do end up using single numbers like 1 or 2 etc, these need to be stable for the lifetime of the given Ubuntu release into which they are seeded.
Hi Alex,
The purpose of these tracks is to align with the policy requirements (which I was involved in drafting). We do not use release naming in tracks because the same track may be seeded across multiple releases and major versions should correspond to the application not the distro they are seeded in. Release versions are used in specific seeded snap tracks that are closely linked with that release, such as the installer, but not otherwise.
Can you explain this concept of āvotingā on tracks? This process is not clear to me and weāre under a fair bit of time pressure ahead of 24.04.1 to get these setup.
Usually thereās a minimum period of a week to get feedback from other reviewers, but this is an exceptional circumstance so that might be waived considering.
What I may suggest from a user perspective is ā1,2,3ā doesnāt really make much sense if we were to imagine e.g āSnap Storeā as a fork of Gnome Software vs āSnap Storeā via Flutter. Although these are the same snap in principal, the tracks arenāt really anywhere aligned as the same software, thereās a huge functionality overlap, but thereās no lineage between the two other than name.
As such Iād personally suggest you might prefer just giving them actual names, or maybe a release/time based naming scheme detatched from Ubuntu itself, so rather than commiting to e.g 24.04, since it might be seeded in other releases too, something like `R24.4" might be an idea until say you have an update in July 2025 that you canāt backport, that now becomes āR25.5ā. Users could then see that a track covers a span in development rather than just arbitrary āversionsā that might be nothing alike.
But also the deadline is short so, Iām not internal, just ideas :).
Hi!
The voting process is defined here in Processes for aliases, auto-connections, and tracks.
I believe the tracks 24.04 and 24.10 make sense, will wait on @alexmurray for the go-ahead for track name 1.
Thanks for the clarification @local-optimum - yes as you say, the exact track names donāt have to correspond to any particular Ubuntu release but I thought for consistency with other seeded snaps this would make sense. However, if you want to share a given track across multiple Ubuntu releases then tying them to a release name is less relevant (although whilst it would be more work for the Desktop team to manage, you could still have per-release tracks and just publish the same thing into them if that is what you need).
Ultimately the need for these tracks are understood - it is up to the Desktop team then to choose the most appropriate names. Although I would recommend using something that users can easily recognise - ie. in this case it should align with the major version number of the project.
+1 from me for the use of tracks 1,2 for snap-store; track 1 for firmware-updater, desktop-security-center and prompting client. Unfortunately I donāt have the permission to create these so hopefully @emmabrostrom can assist there.
Thanks everyone!
I have created the originally requested tracks for all of the listed snaps.
Emma
Thank you Emma! Weāve been able to push the required builds to each of the new tracks now.
