I’d like to request a new track named 1.10 for network-manager (publisher: Canonical). This new track will allow us to publish a new version of the network-manager snap meant for use on Ubuntu Core 18. We also will need a 1.2 track in the near future, so that 1.10 can also be published to latest as well, however this isn’t needed right away.
Per Process for aliases, auto-connections and tracks we need to gather votes from reviewers and tally them at the end of the one-week waiting period.
I see currently network-manager is at 1.2 on latest. SO your plan is to keep 1.2 on latest for the time being and start publishing 1.10 to its track?
Are you happy with people who start tracking the 1.10 track to need manual action to move out of 1.10? that is - people who are currently on latest will magically move from 1.2 to 1.10 when the latter is pushed to latest. But people who opt in to the 1.10 track will NOT automatically move to e.g. 1.30 when that is released in latest or in a putative 1.30 track (unless you do something horrid like publishing 1.30 to the 1.10 track as well).
Just mentioning this to ensure the characteristics of tracks (mainly their stickiness and need of manual intervention to ever move off the track) are taken into account and we don’t get network-manager in a tangle.
Yes, I’m happy with requiring people to take manual action to move from 1.10 to a newer track as we want to stay as close to distro as possible with network-manager on UC18, and it’s unlikely we’ll see a newer release SRU’d to bionic. As for 1.2 devices and latest, I’m also aware of that issue. We’ll need to provide a gadget update to any devices shipping the 1.2 snap which will re-target them to the 1.2 track before we can safely publish 1.10 to latest.
Thanks! +1 on the track request from me, the use case matches how tracks work.
The waiting period has concluded and we have the required +2 votes (well, a +1 and a ) . I have just created the
1.10 track for