Create track for loopchain


snap name : loopchain

Could you create following tracks,




We’ll start a 7-day comment/discussion period and tally the votes to grant these tracks at the end of that period, per Process for aliases, auto-connections and tracks.

I would like some more information on the requested track names, we typically ask for the same for most track requests.

Do you have any documentation on release schedule/cadence for loopchain? i.e. how long is each legacy track supported, and how often are new releases made, which presumably requires creating a new track for the newly-demoted-to-legacy current release? If there’s no documentation on loopchain, it’s fine to just describe the release process/cadence here.

Are these versions of the software typically backwards-incompatible? what happens if I was running 2.2 and then get updated to 2.3?

Thanks in advance!

  • Daniel

Hi. sorry for late reply.

loopchain release irregularly schedule and don’t have documentation now.

At this time, we just need track for internal QA like description.

Could you create just “qa” track?


Thanks for replying!

Not a problem - Can you at least tell me when the versions for which you requested tracks were released, or are planned to be released? (I tried finding this in but couldn’t find anything).

The reason we need this is to establish if the release frequency is slow enough that this looks like a good use case for tracks (but it’s not restrictive, if the semantics are reasonable, a faster release cadence is also OK).

Tracks are meant to allow end-users to stay on stable releases, so they are not a good fit for qa or validation builds. For this, I would suggest publishing your internal QA builds to latest/edge or latest/beta, or using branches (see this for examples on how to use branches). Unlike tracks, branches are self-serviceable by you, and they will auto-close after 30 days which might be a better fit for QA use cases.

  • Daniel

Hi, Daniel.

loopchain 2.4 will be released at the end of the Oct. or beginning of the Nov.
No date for next release is scheduled but maybe six month later.
And loopchain doesn’t plan to support backward compatibility for now.

I understand you said but Skype has insider track for QA team that described in snapcraft docs.
you don’t recommend like this?

In the above output, the Skype snap includes an insider track to publish new builds of the application intended for its internal QA team.

I will try using branch for internal QA.
Can I delay auto-close period(30 days) when using branch?

thank you.

Thanks! This release cadence (and lack of backward compatibility) are a good fit for tracks, so +1 from me as reviewer. (We still need to wait a couple of days for other reviewers to check this and vote).

The Skype insider track is a public preview release, not really for internal QA.

Currently, the only way to delay branch closing is to re-publish the snap that is in there, that “resets” the counter and gives you another 30 days of branch life. It’s easy: simply repeat the release command you used initially. Assuming you had revision 123 released in the latest/edge/qa-123 branch:

snapcraft release loopchain 123 latest/edge/qa-123

  • Daniel
1 Like

Hello @reviewers, could some of you please chime in on this request?


  • Daniel

+1 from me on the release cadence; good candidate for the use of tracks.


We got +2 from reviewers, so I have created the requested loopchain versioned tracks (2.2, 2.3, 2.4), but NOT the qa one as discussed in this thread.


  • Daniel
1 Like