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.
The classic confinement usage is being discussed in [revoked] Classic confinement request for the tree snap .
Thanks in advance!
Just try to
tree /snap/pre-commit/current and it reminds me of this topic
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.
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
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).
I am a reviewer but don’t usually vote on track requests, however, I was part of the other thread and feel this is an appropriate use of a track. +1
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).
+1 to the track request, I agree, I see no problem with this track use-case. Dare I say they should be self-serviced.
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
- 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-classic-confined (this way, not the other around)
As noted in the classic track request for Nano:
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
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).
I’m fine with that. Thanks!
Track is ready to be used (
classicmode) - similar to what we did with nano.