Native App Versions, Patches and Release Channels

1.Three release channels: QA, ALPHA and DEFAULT

A Snowflake Native App reaches consumers through release channels on its application package. Release channels are on by default when you create a package. Once they are enabled, you cannot turn them off. A package created without them can enable them later with ENABLE_RELEASE_CHANNELS=TRUE on CREATE or ALTER APPLICATION PACKAGE. To do any release work you need a role with the MANAGE RELEASES privilege. That privilege covers enabling channels, registering and adding versions and patches, and setting release directives.

The three channels match three stages of the lifecycle. Each one differs in who can install from it and whether the automated security scan runs.

DEFAULT is open to every consumer who can see the listing. QA and ALPHA are not. For those two channels the package keeps a list of accounts, which you manage with MODIFY RELEASE CHANNEL ... ADD ACCOUNTS, REMOVE ACCOUNTS, or SET ACCOUNTS. SET replaces the whole list. You can test any channel yourself with CREATE APPLICATION ... FROM APPLICATION PACKAGE ... USING RELEASE CHANNEL QA. Without that clause, DEFAULT is used. Installing from QA or ALPHA also requires the CREATE PREVIEW APPLICATION privilege.

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

Sources12

2.Creating a version: register it, then add it to a channel

A version usually carries major changes and new features. Every version has its own manifest file and setup script. With release channels, creating one takes two steps. First, REGISTER VERSION builds the version from staged files and creates patch 0 for it. A registered version is not in any channel yet, and a package can hold at most two unassigned versions. If you need a third, run DEREGISTER VERSION on an old one, which also removes its patches.

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

Second, add the registered version to a release channel. Each channel holds at most two versions at a time. This limit applies per channel, not per package, so a package can have more than two versions spread across channels. If a channel is full, you remove a version with MODIFY RELEASE CHANNEL QA DROP VERSION V1. That drop is asynchronous: the version only goes away after every consumer has been upgraded off it.

If you use Snowflake CLI, snow app version create V1 uploads the project files and creates version V1 with patch 0 in one command. It also creates the package if it does not exist yet.

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

Sources12

3.Patch releases

A patch is a smaller update to an existing version, such as a security fix. A version can have up to 130 patches. You create one with ADD PATCH FOR VERSION. If you leave out the patch number, Snowflake uses the previous number plus 1. You can also supply your own number. A patch belongs to the channel its version is in: once a version has been added to a channel, its later patches are bound to that channel. A patch added to a version that is already in ALPHA or DEFAULT triggers the security scan. Unlike versions, patches cannot be dropped.

ALTER APPLICATION PACKAGE <name> ADD PATCH [<patch_number>] FOR VERSION [<version_identifier>]
  USING <path_to_version_directory> [ LABEL = '<display_label>' ]

Sources3214

4.Release directives: default and custom

With release channels enabled, each channel has its own release directives. A directive can only point at a version or patch that has already been added to that channel. The default release directive covers every consumer on the channel who is not named in a custom directive. A custom release directive has a name and a list of ACCOUNTS. You can use one to give a pilot group a newer version or patch while everyone else stays on the default.

ALTER APPLICATION PACKAGE my_app_package
  MODIFY RELEASE CHANNEL ALPHA
  SET RELEASE DIRECTIVE my_custom_release_directive
  VERSION=V1 PATCH=11 ACCOUNTS=(ORG1.ACCOUNT1);

To change the account list of an existing custom directive, use MODIFY RELEASE DIRECTIVE with ADD ACCOUNTS or REMOVE ACCOUNTS. You do not need to recreate the directive. The syntax also accepts an optional FORCE keyword on ADD ACCOUNTS. In Snowflake CLI, snow app publish --version v1 --patch 2 --channel ALPHA --directive customers_group_1 adds the version to the channel and points the named directive at it.

ALTER APPLICATION PACKAGE <name>
  [ MODIFY RELEASE CHANNEL <release_channel_name> ]
  MODIFY RELEASE DIRECTIVE <release_directive>
  ADD ACCOUNTS = ( <organization_name>.<account_name> [ , <organization_name>.<account_name> , ... ] )
  [ VERSION = <version_identifier> PATCH = <patch_num> ]
  [ FORCE ]

Sources15

Exam traps

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

1. 1.On any application package, you create a new version with ALTER APPLICATION PACKAGE ... ADD VERSION ... USING '@stage/path'.Why is that wrong?

   Release channels are enabled by default, and on those packages ADD VERSION USING is not supported. You REGISTER VERSION, then add the version to a channel with MODIFY RELEASE CHANNEL ... ADD VERSION.

   Covered in Creating a version: register it, then add it to a channel

2. 2.Adding a version to any release channel, including QA, starts the automated security scan.Why is that wrong?

   Only adding a version to ALPHA or DEFAULT, or a patch to a version already there, triggers the scan. Adding a version only to QA does not.

   Covered in Three release channels: QA, ALPHA and DEFAULT

3. 3.A faulty patch can be dropped the same way a version is removed from a channel.Why is that wrong?

   Versions can be removed from a channel once consumers have upgraded off them, but patches can never be dropped. You fix a bad patch by releasing another one.

   Covered in Patch releases