Thanks for the detailed reply.
I still think the track naming is awkward, particularly since you said it’s mainly meant as a version for the LMA stack - there’s always the possibility of a new LMA stack coming out in, say, 21.06, and that will be super confusing. Alternatively, if you always publish versions of snaps that work well together to the 20.04 track, that ties the releases conceptually to 20.04, when the thing might work just as well with 18.04 as a base (and I don’t think it would be a very high cost for you to test on both releases).
The above makes me wonder why, if such tight coupling is needed, a single snap containing everything (even other snapped components as stage-snaps) isn’t produced instead of trying to painstakingly align components using tracks in a way that feels like it tries to mimic non-snap packaging systems.
Having said all of the above - since we do have good precedent with snaps using ubuntu-version-named tracks, and as long as you’re aware of the potential confusion for users of this snap with the somewhat inconsistent track naming (some tracks serve a purpose, others serve a different purpose), I’m +1 to granting the tracks as requested (20.04 and 21.04).
Since the Prometheus snap has existing tracks, it’s eligible for Simplified track request process for snaps with predictable cadence, but also since the new tracks deviate from the old ones’ general structure, I’d like to invoke @reviewers to get a few more opinions and perhaps another +1 before actually creating the tracks.
- Daniel