new track for snap: raptor

store
1

Good Day,

We would like to request the following additional tracks for the private snap named ‘raptor’ published by us (IoT.nxt).
It seems there is not a way to add tracks for our own snaps.

prod/stable
prod/candidate
prod/beta
prod/edge

qa/stable
qa/candidate
qa/beta
qa/edge

We are releasing a new major version with additional security measures that is not backwards compatible. We need to release the new version to a select group of customers without breaking those on latest/stable, latest/candidate etc.
We cannot use branches for this as these additional tracks will be have a longer application lifecycle that the allowed 30 days.

Thanks,
IoT.nxt
Ps: For some reason our company email domain cannot register on the forum (@iotnxt.com)

1 Like
2

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
3

Daniel,

Thank you for your response.
We have had a fast-development cycle to get some functionality into the field - thus edge, beta, candidate and stable all currently carry production releases - yes, I know - not the way to do it, but sometimes…

My solution to get around this temporary holdup that prevent getting the next gen version out as follow

  1. Create a prod/stable (for all future clients) and a prod/edge -> prod/edge just to make sure we test the process of releasing to track before doing it ‘for real’ - would hate to break the stable channel due to a lack of knowledge on release command-line usage.
  2. release the new version that will become the defacto version to prod/stable.
  3. use prod/stable for all future versions – forever.
  4. Migrate and test current client installs one-by one to prod/stable - ideally in 6 months all production releases will be on prod/stable -> but this depends on any compatibility issues with the new version
  5. delete (support request) all revisions in the snap store apart from prod/stable -> this is required as the earlier versions has some … (NDA) that cannot be made public.
  6. change the snap to be PUBLIC.

The reason for the track (prod/stable) is that I do not want to go back to all installations and move them from prod/stable back to (latest)/stable - I would rather live on prod/stable forever, and the use latest/stable for new versions that passed QA but is not yet ready for all customers.

Having at least prod/stable and prod/edge mitigates my risk with the new version that is not 100% backwards compatible. This cannot be a branch as prod/stable need to live forever.

After the track above is created and in use, we will play nice and ensure that we manage releases properly by releasing to edge and then pushing the revision to beta, candidate and then latest/stable, prod/stable as the channels were supposed to be used.

The only diversion from my statement above is that we have some bigger corporate clients with specific mandates as to releases, they may require their own track to prevent holdup to our other customers. This is however not something I will do easily as I know from experience maintaining multiple releases is just

I hope this clarifies and supports my immediate requirement and the reasons for it.

PS: I did some proper research on using branches and I have already started using a branches for targeted debug/qa releases as I have no problem with these branches disappearing in the near future.

4

I’d like to stress the point Daniel made above: if you are installing your snap on devices using a logged in publisher or collaborator account, and then distributing those devices to customers, you are allowing anyone in possession of a device to have write access to your snap in the store.

If that is indeed the scenario, I suggest you stop doing that, change credentials for those accounts, and make a new snap for the public version.

I would also encourage you to contact us regarding our Brand Store offering which is designed specifically for commercial IoT vendors like IoT.nxt and provides a private store for your devices among other benefits.

5

Thank you for your response.
I do see reason in what you are saying and will advise the CTO and the team as such.

PS: Currently, we have a limited (but larger) installation base 100% under our control, with this will change soon.