Request 3 tracks for snap "mtk-neuropilot"

Hi all,

I would like to request 3 tracks for my snap that enables neuropilot ecosystem for Mediatek’s Genio product line. Each track should have the name of the respective hardware board:

  • “g1200”
  • “g700”
  • “g510”

If any questions, contact me on MM - asaly12.


Per Process for aliases, auto-connections and tracks 2, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have four questions before casting my vote.

  1. What’s mtk-neuropilot’s release cadence, how often is a new major version (potentially requiring a new track) released? Is this documented somewhere by upstream?
  2. Is there some commitment from upstream on maintenance of old versions?
  3. Are new versions backwards-incompatible? Meaning, if I was running g1200 and try to install g700, will that just work, or do I need to migrate my data/configuration, or will things break horribly?
  4. Is there a possibility of introducing a new set of changes for a specific hardware board, that could potentially require a new track only for that board? E.g. Say I’m using g1200 and a new version of mtk-neuropilot is released that’s backward-incompatible with the existing version for g1200. New tracks for g1200 (e.g. g1200-a) would then need to be created, for every such case, no?



Hi Odysseus!

I wanted to give some context, the project is in early stage and is not intended for wide audience, but only for my teammates in Canonical and Mediatek to exchange feedback. I only intend to use --candidate channel for now. I’m still working on the snap, so it will change a lot. Maybe you can give me advice on how to “unlist” this snap, so you can’t find it in the search but it’s still available if you have the link? For now I made it public only because I want to enable my teammates running snap install XXX.

Back to your questions:

  1. There’s no release cadence from our Mediatek partner to the best of my knowledge. Asked Mediatek to be sure, I’ll get back to you.
  2. My gauge is that there will not be any maintenance of old versions. Asked Mediatek to be sure, I’ll get back to you.
  3. I think you’re misunderstanding the names, g1200, g510 and g700 are not versions of software one preceding another but three separate development boards that exists in physical space at the same time (please correct me if I misunderstood your question). You can install g700 snap on g1200 board, nothing horrible will happen, but you might not be able to use the APU (not a big deal, kind of like you’re not able to use hardware acceleration of your GPU but the whole system still works with no issue). But usually you don’t install g700 snap on g1200 hardware.
  4. Please correct me if I’m wrong, but I plan to use branches or release channels for the newer versions of software per board. Let’s say we released mtk-neuropilot, track=g1200, release_channel=latest, then we got an update from Mediatek, we move the old snap to mtk-neuropilot track=g1200,release_channel=v1.2.3 and update the release channel “latest” with the new software. I understand this is a weird usage of tracks (usually used to track software revisions), but we have this situation here where we need to snap (almost) the same software for 3 different hardware boards. If you have any better idea of how to achieve that I’d be most grateful to know.

This is something I can do for you. Let me know if you want me to proceed with unlisting your snap.

latest is not a release_channel :)- it’s the (implicit) default track for your snap. Channels are better explained here and here - I would suggest a read of those resources to get more clarity on how tracks work and how they relate to a channel specification (track/risk/branch ).

Up until you mentioned v1.2.3, I thought I’d understood your use case. For example, I assumed you’d have the g1200 track which means you’ll also have the g1200/stable, g1200/beta, g1200/candidate and g1200/edge channels. When Mediatek would issue a new update, this would fall under e.g. g1200/edge, then once you’d test it you’d promote it to g1200/beta and so on and so forth.

But now, with you mentioning v1.2.3, I’m a bit confused. This seems like a software version (a primary candidate for track names) and I’m unsure what’s its use case for the different boards. Would it make sense to create tracks based off the version itself, instead? So, for example, the v1.2.3 would give you the v1.2.3/stable, v1.2.3/beta, v1.2.3/candidate and v1.2.3/edge channels. When a new version comes out that’s incompatible with v1.2.3 (e.g. v.2.0.0) a new track for that version would be created etc etc. What do you think?

Hi Odysseus,

Let me know if you want me to proceed with unlisting your snap.

Yes, please unlist my mtk-neuropilot snap.

latest is not a release_channel :)- it’s the (implicit) default track for your snap

You’re right, I misunderstood the terminology. And the usage of v1.2.3 was misguided because the upstream, to the best of my knowledge does not issue releases (at all, see

Now I’ve read the docs and I see that tracks are used to control “lateness/versions”, risks control “matureness” and branches are temporary. I see that I cannot use tracks to distinguish hardware versions, because then I’ll miss out on the “standard” usage of tracks. Probably, I will have to create 3 snaps for each hardware board :frowning:

Let’s close this issue and I’ll proceed with the idea. Could you also unlist my snaps (not published yet): mtk-neuropilot-g1200, mtk-neuropilot-g510 and mtk-neuropilot-g700?


I unlisted mtk-neuropilot. Unfortunately, I couldn’t do the same for mtk-neuropilot-g1200, mtk-neuropilot-g510 and mtk-neuropilot-g700 as they are still pending review and do not have any published revisions. Let me know once their review is complete and I’ll happily unlist them too.