Dear @reviewers, I would like to request the classic track for the tree snap. This track is meant to provide an alternative distribution of the tree command that is in classic confinement while shipping the strictly confined ones in the latest track simultaneously.
Sorry! At this point, weâre in âextensionâ territory since we didnât get enough votes in the first 7 days of voting. @reviewers, could you please have a look and cast votes/opinions on this request? Weâll check for any votes or results on April 29th.
This is similar to New track(classic) request for the nano snap (which is also awaiting resolution). The version of the software being shipped in latest and classic is generally the same, which is not what tracks were envisioned for.
As for nano, classic has to be granted for the snap anyway (i.e. granting the track doesnât negate the need to approve classic confinement for the snap which would be used on some revisions and not others) - Iâm not sure I see much point on having the non-classic version available as well, as the usability will be much reduced (about the only use case I see is install-ability on Ubuntu Core systems, IMO much less of an issue with tree than it is with nano).
Consistent with my thoughts on nano, my particular vote is -1 out of being strict on track semantics and purpose (though Iâm hoping other reviewers can chime in and we can suggest a good alternative for this use case).
Hello - This request still doesnât have the required number of + votes (current tally is +1/-1). @reviewers, could I get a few more eyes/votes on this request?
Extending the vote/comment period for another 3 days (yes, 3 days, Iâve been doing it wrong!) - weâll check back on May 2nd).
I appreciate all the input on this new idea for usage of tracks, but given that it is a departure from original design and guidelines Iâd like to discuss with some others before we open the gates for this as a general pattern.
@pedronis@niemeyer@mvo - could use your input on this usage of tracks for differentiating between classic or strictly confined versions.
So a âclassicâ track is not a version of the underlying software but it is a version/variant of the snap, in general this proposal also shows that once thereâs a way to carve a namespace it will be used, we have track and branches with very defined purposes, but people will try to color a bit out of the margins, we need to be aware here. I have the following considerations anyway:
we are trying to get strict snaps as much as possible, not classic ones, so we should have âclassicâ tracks, not âstrictâ ones if we adopt this. We absolutely shouldnât do this both ways.
as I said elsewhere there might be software where âclassicâ is an upstream designation of an actual version stream so I do really prefer if we do this the more cumbersome classic-confined name
we ideally shouldnât really do this for anything that expects actual version tracks but if that happens we need to be ready to live with things like this:
1.0
1.0-classic-confined (this way, not the other around)
Sorry for the delay. We did discuss this and would like to propose classicmode as the track name, to avoid conceptually conflicting with other meanings for classic.
If this is OK with you, I can create this track.
(For reference, most of the Snap Store reviewers and one architect were present in the discussion so the votes were cast in person).