Announcing channel branches

store
1

As part of our enhanced channels effort, and as a complement to our previous announcement on tracks, let us now introduce ‘channel branches’.

Below each <track>/stable channel you can create ephemeral ‘branch’ channels for hotfixes or other short-term releases. A channel now becomes a tuple of > track/stability[/branch]

Branches can be created directly from snapcraft with a name of your choosing. A branch is created when you first release a revision into it. Branch channels will only live for 30 days, after which they will be automatically closed. Any subsequent releases to the branch will reset the 30 day expiration.

Branches can only be created below the stable risk, in any track. You can think of them as hotfix channels. For example, instead of releasing an update to stable for everybody, you can release to a ‘hotfix-1’ channel, and then ask affected users to snap refresh --channel=stable/hotfix-1. When branches close, users subscribed to the branch channel will fallback to the most appropriate channel, stable in this example.

Other than that, branches behave like any other channel: you can release a different revision to it, you can close it, and you can refresh or install from it.

Snapcraft 2.30 and snapd 2.25 have changes to improve the experience using branches, but you can start trying them right now:

snapcraft release <snap> <revision> [<track>/]stable/<branch>

For example:

snapcraft release foo 14 stable/hotfix-1
snapcraft release foo 15 2.1/stable/bug-123

To install a snap from a particular branch:

snap install foo --channel=2.1/stable/bug-123

You should let your users know if you have any branches available via your blog or mailing lists since they are not discoverable through the snap command.

Feedback welcome and if you have any questions, please ask!

For more information on Channels, see here.

5 Likes
2

Note we’ll be making a change to allow branches on non-stable risks, see discussion Using branches on non-stable channels

2 Likes
3

Also we are working on a bugfix for an issue with fallback when the branch channel is closed.

4

The “fallback” bug is now fixed.

The following is the current behaviour, then…

A given version of the package is released to a branch, for quick availability of a fix that is need by some people but that still can’t be released to stable. For this example, I released revision 2 to stable/hotfix, and installed the package from that branch:

$ snap install currate --channel=stable/hotfix
currate (stable/hotfix) 0.3 from 'facundobatista' installed
$ snap list currate
Name     Version  Rev  Developer       Notes
currate  0.3      2    facundobatista  -

Some time later, a new version of the software reachs stable, cointaining the fix you needed among other improvements.The developer may choose for closing the branch, or she can wait for its normal automatic closing (branches expire 30 days after last release).

For our example, I released revision 5 into stable, and then closed the branch. See what it would like:

$ snap info currate
name:      currate
summary:   "Get currency rates"
publisher: facundobatista
description: |
  Show the exchange rate from two currencies

commands:
  - currate
tracking:    stable/hotfix
installed:   0.3 (5) 10MB -
refreshed:   2017-04-26 20:20:52 -0300 ART
channels:            
  stable:    0.3 (5) 10MB -
  candidate: 0.3 (5) 10MB -
  beta:      0.3 (5) 10MB -
  edge:      0.3 (5) 10MB -

Check in that output that there’s no branch in the channels section, but it indicates that the system is tracking the stable/hotfix branch.

But as I said, that branch is already closed, so if the system is refreshed, it will fallback to the normal channel (stable in this case):

$ snap refresh currate
currate (stable/hotfix) 0.3 from 'facundobatista' refreshed
$ snap list currate
Name     Version  Rev  Developer       Notes
currate  0.3      5    facundobatista  -

Any doubt or detail about these behaviours, just ask!

Regards,

5

Hi Facundo,

if snapd does its automatic refresh, will it make the snap fallback to stable? (in this example), or does this happen only when the user forces a refresh?

Best,

6

On all refreshes, no matter if manual or automatic.