Track request - network-manager/core18

store
1

Hi, we’d like to request a core18 track for the network-manager snap.

The current default track uses core16, and moving it to core18 would be very risky, so we prefer to have a new track for the new NM versions that will use core18 as base.

Thanks!

2

Hello,

This transitional case would be better handled with epochs as explained in Track request - multipass/core16, but as explained there as well, currently using tracks is a reasonable option, and your explanation seems to match that use case. +1 from me.

There’s a 7-day waiting period to gather more votes (we need at least two positive votes from reviewers/architects); once the time has elapsed, I’ll check and act as per the state of voting at that time.

Cheers!

Daniel
1 Like
3

Hello,

Well, after discussing a bit with wgrant, I need to retract my suggestion to use epochs, since they don’t cover this case at all because there’s no incompatible data that epochs would allow migrating via an intermediate snap (which might be the case with multipass). So - please ignore that :slight_smile: Cheers.

  • Daniel
4

+1 there’s no safe transition method to core18, and it makes sense for NM to be as bulletproof as possible.

5

Notice that you’ll need new snapd (not implemented) or ubuntu-image features to be able to effectively use this track when building devices.

6

Hello so - Entirely my fault. I completely forgot about Track Request: network-manager 1.10 and I only found the existing 1.10 track as I went in to create the core18 track. But I had to stop creation of the new track because, as you will notice in the 1.10 request, the intended purpose of the existing 1.10 track is

This new track will allow us to publish a new version of the network-manager snap meant for use on Ubuntu Core 18

This seems to make the core18 track redundant. In light of this new information, I have delayed creation of the core18 track and would like to ask for @abeato’s explanation on whether both names are indeed needed or we can drop the core18 request and keep 1.10 instead.

  • Daniel
7

We’re going to discuss this topic at our next network/telephony meeting this Thursday, and will get back to you. It’s not clear to me that we want both…

8

I didn’t weigh in on this but naming tracks after bases seems to require to be a bit careful. It’s worth to think what later track by versions if needed would need to look like. Would they all be just core18, will they need to have core16 and core18 variants. If a snap has both kind of tracks, some that are base name, some that look like version how will the user orient themselves?

9

Also worth noticing that similar (but maybe different) tracks for things like the kernel are “18”, not core18.