Native App Release Channels, Versions and Patches

1.QA, ALPHA and DEFAULT release channels

Release channels let a provider publish an app at different stages of its development lifecycle, and run several versions and patches at the same time. Release channels are enabled by default when you create an application package. If you created a package without them, you can turn them on later with ENABLE_RELEASE_CHANNELS=TRUE on CREATE APPLICATION PACKAGE or ALTER APPLICATION PACKAGE. This is a one-way decision: after release channels are enabled for a package, they cannot be disabled.

The framework supports three channels. They differ in who can reach them and whether the automated security scan runs.

ALPHA has one subtlety. While the security scan is still running, the provider can already set the release directive for the version, and consumers can install it. If the scan then fails, the version can no longer be used. DEFAULT is the production channel, and everything assigned to it must meet the security requirements for publishing an app.

Sources12

2.Targeting accounts and release-management privileges

By default, only the DEFAULT channel is open to every consumer with access to the listing. QA and ALPHA must be enabled explicitly for specific accounts, and the application package keeps a list of the accounts in each of those channels. You edit that list with ALTER APPLICATION PACKAGE … MODIFY RELEASE CHANNEL, using ADD ACCOUNTS, REMOVE ACCOUNTS or SET ACCOUNTS.

ALTER APPLICATION PACKAGE my_app_package MODIFY RELEASE CHANNEL ALPHA ADD ACCOUNTS=(ORG1.ACCOUNT1);

SET ACCOUNTS does not add to the list. It overwrites the list. Every account that is not in the new list is removed from the channel.

ALTER APPLICATION PACKAGE my_app_package MODIFY RELEASE CHANNEL ALPHA SET ACCOUNTS=(ORG1.ACCOUNT2);

The documentation names privileges for release management in more than one place. The release-channels guide says a role needs MANAGE RELEASES. That privilege lets the role enable release channels and the QA and ALPHA channels, register and deregister versions and patches, add versions and patches, and set the release directive. The SQL reference for MODIFY RELEASE CHANNEL instead lists OWNERSHIP on the application package, or the account-level MANAGE VERSIONS privilege. MANAGE VERSIONS lets a role modify release channels and release directives on any application package without owning it.

Installing from the test channels is controlled separately. To create an app from QA or ALPHA, even in your own account, the role needs CREATE PREVIEW APPLICATION.

Sources13

3.Channel choice and monetization

The channel an app is installed from decides how it is billed. Every instance installed from DEFAULT uses the pricing plan configured for the listing. Instances from QA and ALPHA are free, because they are meant for testing. Only DEFAULT is meant for production.

The channel also limits how many instances a consumer can have. A provider enables multiple instances with the MULTIPLE_INSTANCES property on the application package, and the setting applies to every channel in the package. Even so, on a paid listing a consumer can have only one DEFAULT-channel instance.

Trials work differently by channel on limited trial and paid (with trial) listings. A QA or ALPHA install is free and is disabled when the trial ends. If it was installed from a paid listing, though, it stays available after the trial. To revoke it, the provider removes the consumer from the channel's active targets. A DEFAULT install is disabled when the trial ends, and to keep using the app the consumer must accept an offer and select the app from the DEFAULT channel.

If the USING RELEASE CHANNEL clause is left out of CREATE APPLICATION, the app is installed from DEFAULT.

CREATE APPLICATION my_app
  FROM APPLICATION PACKAGE my_app_package
  USING RELEASE CHANNEL  ? ;

Putting the channel types and their monetization implications together: the three channel types split into one production channel and two testing channels, and that split is what drives monetization. DEFAULT is the only production channel, and it is the only one whose installs are billed at the listing's pricing plan. QA and ALPHA are testing channels, so their installs are free and never use the pricing plan, whichever listing they came from. That makes channel membership a commercial control as well as a release control: an account added to QA or ALPHA gets a free test instance, while a consumer who should pay must install from DEFAULT.

The implications reach trials and instance counts too. On a paid listing, a QA or ALPHA instance outlives the trial unless the provider removes the consumer from the channel's targets, whereas a DEFAULT instance is disabled when the trial ends until the consumer accepts an offer. A paid listing also caps a consumer at one DEFAULT instance, while QA and ALPHA instances can be multiple. So a provider should not leave a paying customer on a test channel: it is free, and access continues after the trial.

Sources1

4.Registering versions and adding patches

Versions usually carry major updates such as new features and changed functionality. Patches should carry only small updates, such as security fixes. Each version and patch needs its own manifest file and setup script.

With release channels enabled, the legacy ADD VERSION USING '@stage/path' clause is not supported. Instead, you register a version in the package, then assign it to a channel. Registering creates the version and its patch 0, but does not put it in any channel.

ALTER APPLICATION PACKAGE my_app_package REGISTER VERSION V1 USING '@stage/path';

ALTER APPLICATION PACKAGE my_app_package MODIFY RELEASE CHANNEL QA ADD VERSION V1;

Each limit applies at a specific level. A package can hold at most two unassigned versions, so to register a third you must deregister one first. The two-version limit applies to each release channel, not to the whole package, which is how channels let a provider run more than two versions at once. Within a version, patches are not capped at two: a single version can have up to 130 patches. Patches cannot be dropped. When you add a patch without a number, Snowflake uses the previous patch number plus 1. Version identifiers can be at most 30 characters long. When a version is added to a channel, its later patches are bound to that same channel.

Sources142

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.MODIFY RELEASE CHANNEL … SET ACCOUNTS appends the listed accounts to the channel.Why is that wrong?

   SET overwrites the list, so any account left out is removed. Use ADD ACCOUNTS to append.

   Covered in Targeting accounts and release-management privileges

2. 2.An app installed from the ALPHA or QA channel of a paid listing is billed at the listing's pricing plan.Why is that wrong?

   Only DEFAULT installs use the listing's pricing plan. QA and ALPHA installs are free.

   Covered in Channel choice and monetization

3. 3.On a package with release channels you can still create a version with ADD VERSION … USING a stage path.Why is that wrong?

   That clause is not supported once channels are enabled. Register the version, then add it to a channel.

   Covered in Registering versions and adding patches