Please create
Tracks for the subiquity snap, as we need to comply with the https://wiki.ubuntu.com/UbuntuSeededSnaps policy and publish different subiquity snaps depending on what the target installation media is capable to support.
Hello!
So the policy you pointed to reads:
Snaps included in images will be installed referencing a per-Ubuntu-series branch following the name format ubuntu-$version (e.g.: ubuntu-16.04). This ensures forwards-compatibility by allowing publishing to this branch if the mainline of a snap becomes incompatible with a given Ubuntu release, without requiring up-front maintenance of multiple snap channels.
it explicitly mentions branches, but branches are by design ephemeral and non-discoverable. Your use case seems to imply tracks, however I prefer not to make assumptions, since creating the tracks also carries a commitment from the snap’s maintainers to keep the snaps up to date with, at the very least, security updates, per Process for aliases, auto-connections and tracks, https://docs.snapcraft.io/channels/551 and https://blog.ubuntu.com/2017/09/07/controlling-snap-releases-with-channels-tracks-and-branches-part-2.
Based on this, would it be possible to first clarify what is meant, in the UbuntuSeededSnaps policy page itself, and once it’s been determined that tracks are indeed what you want, we can look at the request again?
Also, since 18.04 and 18.10 are already released, could you describe the plan to “retrofit” the track into those releases? since as far as I can tell, the released images are pointing to latest/stable for the subiquity snap.
Thanks!
why the ubuntu part of those track names? will there be non “ubuntu” tracks?
The branches approach mentioned in the policy makes sense if:
Those branches are not yet existent, they would be created at the time that there is divergence and the old releases would need to be given old versions or conservatively patched old versions of the snap, but not what is currently stable.
If the expectation is that there is divergence immediately then using tracks from the start is more sensible. Then there is the question if that naming convention for “divergence hatches” branches should be used for tracks or not. We have tracks that have major versions has name, some other for example for core 18 gadgets that are just 18 etc.
Re: stable images
We are still producing images for those, and will change them for point releases / respins. And need to control what subiquity will go into them.
Good question as to what the policy really means. I guess I need to ping @slangasek about that. Can you please clarify if the policy? does it mean tracks or branches, or branches that point to a track? Cause i see that e.g. lxd has tracks and branches, but it’s impossible to see what the golden standard for this is supposed to be. I shall publish subiquity into stable/ubuntu-18.04 stable/ubuntu-19.04 tracks? Or do we need/want bionic/stable/ubuntu-18.04? cause bionic is going to be like a 3year track or so.
Existing seeded snaps use intentionally expired branches because it’s expected that latest/stable will be usable for the life of the Ubuntu release, but an escape hatch is required. In normal situations the branch just falls back to latest/stable so every Ubuntu release gets the most recent version, but it allows for the unlikely case that divergence becomes necessary later.
For something more deeply integrated with the image and distro like subiquity, it seems likely that newer codebases won’t necessarily work on a five year old Ubuntu release, so using tracks instead might make sense. Divergence might be expected, not required for an unlikely escape hatch.
@wgrant Interesting points.
We used to only build images for one release and we used to disable snap refresh too. But now, we do want to start offering subiquity snap refresh in the live session - to potentially allow people to live upgrade the installer, to gain new features and/or fixes.
Thus this question is coming. So far we have kept [latest]/stable at whatever we want to build bionic with. But This is not sustainable, if we want to offer “SRU” fixes for disco for example.
I guess we can just continuously publish what we want into the branches, and never touch stable again which will thus freeze at whatever we shipped 18.04.2 with…
I guess I’ll need to talk with @mwhudson about our strategy here. As the snap-refresh UX/code is about to land into subiquity edge channel.
We do not want to use branches for subiquity. If people want to talk about the policy around their use in Ubuntu they should do that in some other thread 
Subiquity has always been a bit of an oddball snap, because it only runs in the live environment which has auto refreshes disabled and so there has been no need for snaps. But 19.04 will add the feature of checking the store for updates and offering an upgrade to the user. So this adds a motivation for the track: we don’t want the user booting the 18.04.3 installer to download a version of subiquity that offers options that only apply for Ubuntu 20.04 or newer and the obvious way of preventing this is to have per-Ubuntu-series tracks.
Part of the reason we haven’t asked for this before though is that this is so far only a theoretical consideration: there have been no changes to subiquity that would not work on an 18.04 system, and more than that, I don’t think any such changes are even planned at this time (maybe @xnox has something in mind here). So we could be “lazier” about this by having all images include and track subiquity from stable until we have a version we don’t want to be offered on older series, in which case we could add the tracks. This would end up in the slightly strange situation where latest/stable would not actually be the newest version of the snap, which would be a bit strange.
If we do go with the snaps, I think track names of “18.04”, “19.04” etc would be fine (i.e. drop the ubuntu- prefix). Also there’s no need to create a track for 18.10, we’re not going to be making new cosmic media again.
This does absolutely refer to branches, not tracks. The intention is for this to be a low-cost escape hatch that we only pay the cost for at the time we have to use that hatch - at which point we would have a conversation with the Store Team about an exception for the auto-closing of the per-Ubuntu-release branch channels.
Yes, I was wrong, branches are a better fit. That means this track request can be disregarded.