Hello!
This is by design; tracks must be requested explicitly and reviewed/approved by us because we want to ensure the publisher understands their nature and the use case is a good fit for tracks.
An important feature of snaps is auto-refreshing, to help users stay up to date which improves their security. Tracks modify this behavior slightly: once a user decides to start following a track, only updates to that track will be installed when refreshing. Because of this, we want developers to be very aware of how tracks behave, and commit to ensuring relevant updates are propagated to tracks as well. As such, tracks need to be requested in the Snapcraft forum, approved by reviewers and created by a store administrator.
Tracks can be used to have multiple “stable” versions, so users can choose to either follow the latest “stable” or use an older major version, usually for compatibility reasons. Branches are custom “temporary” channels to which a snap can be released and are useful for releasing “hot fixes” and code changes that apply to limited audiences.
What you’re requesting here is a prod track and a qa track (each with their set of risks, stable - candidate - beta -edge). However the naming scheme does not seem to correspond with tracks’ expectations. Usually the track names identify stable versioned releases which will remain relatively “frozen”, but your “prod” and “qa” tracks suggest that any version undergoing QA will be in “qa” and move to “prod” when it is released. Even if this is not your intent, it’s what the names suggest and it is somewhat confusing. Would perhaps tracks named after version numbers better fit the use case?
I actually think your use case could be served by either tracks or the beta/edge risks. You said:
Can you release the new version to latest/beta or latest/edge?
Or maybe we can use branches as follows:
You can extend the lifetime of a branch by rereleasing to it, and it can even be the same revision. Example, assuming you want to put revision 45 on a branch for longer than 30 days:
snapcraft release raptor 45 my-testing-branch
Then, 29 days later:
snapcraft release raptor 45 my-testing-branch
This extends the branch’s lifetime by a further 30 days.
I’d like to know your response to these ideas so voters (me included!) can cast a vote on whether this track request is granted.
I have two additional comments.
Raptor is private, however you say:
Are you perhaps sharing your Snap Store username/password, or that of a collaborator account, with these customers? I’m asking because that’s the only way others can install a private snap, but it’s also quite risky because anyone with those credentials is able to push changes to the snap. Private snaps are meant for closed development since all the collaborators have write access.
My second comment is for this:
Would you mind posting this again (along with any error messages you get from the forum) in the Forum category so the forum admins (a separate group from reviewers such as myself) can look at it?
Thanks and looking forward to getting more information on your needs and use case!
- Daniel