Create new track for "cluemaster-mediadisplay-core"

store-requests
1

Hello. I’m requesting a new track to be added called “DEV”. I would like a separate track for us to use solely for our development builds which point to an entirely different set of servers for us. It gets confusing sometimes when our builds are mixed in the default track if we forget to change the yaml snap version names.

2

Hi there!

Per Process for aliases, auto-connections and tracks 2, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.

I have three questions before casting my vote. The following questions also apply to the other two snaps that you are requesting a DEV track for, cluemaster-videoplayer-core and cluemaster-roomcontroller-core.

  1. What are the snap’s release cadence? How often is a new major version (potentially requiring a new track) released? Is this documented somewhere by upstream?
  2. Is there some commitment from upstream on maintenance of old versions? Will older versions be supported when newer versions are created?
  3. Are new versions backwards-incompatible? meaning, if I was running non-DEV and try to install DEV, will that just work, or do I need to migrate my data/configuration, or will things break horribly?

Thanks!

3

Hello. Thanks for checking. I want to withdraw my requests for a DEV track. After further discussion, we might want to use track names for Core OS and hardware compatibility instead just like Ubuntu-Frame does with tracks based on the OS builds they are compatible with. We will consider our Edge and Beta Channels for our internal development-only versions that point to dev servers and have debugging code unless there is a better way you suggest we do this?

To answer your questions.

  1. The apps are not for public use. They are only installed on Core OS and by the staff of ClueMaster for proprietary devices. We will likely follow the track based on the CORE OS compatibility builds in the future like Track 24 or Track 26 when we update our code.

  2. This is not a public app so there is no commitment. We manage all devices sold with our snaps.

  3. Dev was intended to be used for our dev team to since it uses different server connections and tools while the development and maintenance of our snaps occur. Once we have a stable build, we change all our code to point to production servers and publish the final snap first on Edge to test, then beta with some select beta customers, then switch to stable so all our customers get the update on our managed devices.

1 Like
4

Hi, @ClueMaster !

I suppose using edge and beta channels for your internal processes is fine. You could also have a look at branches, they could be useful for some urgent bugfixes or for dev purposes: https://snapcraft.io/docs/channels#heading--branches

Have a great end of the week!