Dear @reviewers, I would like to request the 16 track for the zenity-integration snap. zenity-integration is a stage snap for packagers to integrate Zenity into their snaps, the core16 track allows it to be available to consumer snaps that are using core , and the upcoming core16 base.
Thanks in advance!
Hello!
We’ll start the comment/vote gathering process to run until April 18th.
Being consistent with my thoughts in Request core18-3.4 track for ffmpeg-sdk-gplv3 stage snap, I don’t feel tracks are appropriate for “library” snaps. To repeat myself, tracks are meant to “give a group of users the ability to stay on a robust, proven version of their software, even when a newer stable version has been released. Using a track can be useful if the newer stable version has some backward-incompatibilities”. This is not the case with zenity-integration, I believe, since it’s meant to be included in other snaps; further, it’s unclear to me how a developer would use this zenity-integration and what happens if the base: requirement for the main snap conflicts with that of the zenity-integration included snap. Could you provide an example of how I would use zenity-integration in my snap?
On the plus side, we do use tracks to allow a snap to support two different core versions, in such a case the tracks are typically 16 and 18 (not core18 or core16).
I’ll wait to read your reply before casting a vote (and remember, regardless of my vote, we need a +2/-2 by reviewers at the end of the voting period to make a final decision).
Thanks!
As I mentioned in my previous reply, that really depends on the perspective of what the users are, which in this case are the stage snap consumers. As stage snaps is a new concept previous conventions will obviously need some adaption to it.
it’s unclear to me how a developer would use this zenity-integration
Should attach it in the first place, apologies:
what happens if the base: requirement for the main snap conflicts with that of the zenity-integration included snap
That isn’t a supported setup in the first place, which is documented in the prerequisite section of the aforementioned forum topic.
we do use tracks to allow a snap to support two different core versions, in such a case the tracks are typically 16 and 18 (not core18 or core16).
I followed the naming fashion of the multipass snap, but that always can be adapted 
@reviewers, the comment period for this track request has elapsed and we only have +0/-1 votes. Could some of you please have a look and cast a vote?
Extending the voting period until April 25th.
+1 on the 16 track. This use of tracks makes perfect sense to me as a stage-snap user.
Review period extension has finished and we still only have +1/-1 votes.
I’ll extend this again until May 2nd.
@reviewers your help voting on this request would be appreciated
Hello,
The current vote tally hasn’t changed (+1/-1) - however, this request is similar to Request core18-3.4 track for ffmpeg-sdk-gplv3 stage snap which is being discussed as a general pattern. I think it’s prudent to wait for the outcome on that one to be taken as precedent before acting on this one.
No worries, once the discussion on track usage for stage packages is resolved, we can apply the results generically to any requests.
