Snapcraft's 21.10 Roadmap

The Snapcraft roadmap has been a mystery to most. To solve that, I am presenting the current roadmap for Snapcraft for the 21.10 cycle (which is somewhat aligned with the Ubuntu 21.10 cycle).

Tentative versions and their release dates can be tracked. Links to specifications will be added as they are drafted or approved. Feel free to raise a hand if any of these items match your interests or expertise.

The date specified under each proposed version is the tag date; a version is released to the candidate channel on that day, or the next, depending on infrastructure capacity. A call for testing is made for early participation, lasting a week, after a release reaches the candidate channel.

As usual with any plan, it is subject to change if the need arises.

Snapcraft 4.8



Remove experimental flag from package repositories

This feature is finally stable and is documented at

Bug fixes

apt cache: improve error handling when packages do not have candidates available

project: validate snapcraft yaml before using it

ua manager: install ubuntu-advantage-tools as needed

build providers: set hostname for lxd

dotnet plugin: use https for release metadata url

Snapcraft 4.8.1


This release’s theme was mostly about displaying a warning when using core as a base or no base at all.


Channel switch warning when using base: core or no base

A warning to be displayed when using no base or base: core in snapcraft.yaml, ensuring publishers dependent on this support know they need to move to the 4.x/stable channel.

Bug fixes

Log to stderr

Print warnings and errors to sdtderr and also log warnings to stderr.

repo: normalize if stage-packages and check types

Snapcraft would incorrectly operate on stage-packages even if no debs were defined (affecting stage-snaps). It would also incorrectly glob directories ending in .pc

Snapcraft 4.8.2


Bug fixes

Not able to run snapcraft login on mac m1

Update brew installation command for multipass

Snapcraft 4.8.3


Bug fixes

Remove pysha3 dependency from snapcraft

Fix whoami schema

Add ReviewInProgress status

Snapcraft 5.0

This release has an emphasis on cleaning up the code base to remove the use of core. This will be transparently supported on and Launchpad by using Snapcraft’s 4.x channel track.


Snapcraft Metrics command

Add the possibility of viewing the status of a given snaps population segregated by OS/distribution

Add Metadata Links to snapcraft.yaml

New feature to add links to snapcraft.yaml in a friendly way that get translated into a more wire protocol friendly syntax for snap.yaml which in turn would be consumed by the Snap Store for presentation purposes. Links would be those like: donation url, contact, issue or bug tracking, etc.


Replace Snapcraft’s use of the Snap Store’s account-info with whoami

This task has been dropped.

This API endpoint is much faster, older Snap Store APIs require passing in the snap-id which this can help improve performance on.

Remove unsupported bases from spread tests

The unsupported tests are essentially those that require core or no base. Those will be kept in the 4.x branch.

Remove support for base core16

While core16 never came to be, Snapcraft has had logic around this to support it once it was available, now that Ubuntu 16.04 has entered ESM, it is no longer useful to have moving forward.

Remove support for base core

This is one of the reasons for the version bump to 5.0. Publishers needing continued support for base: core will be using the 4.x track.

Remove snapcraft-legacy re-exec entry point

Snapcraft has for the longest time, since the introduction of bases, kept two code bases inside the same product. When no base is detected, Snapcraft would have re-executed itself into the old code base. The absence of a base in snapcraft.yaml triggered this behavior for backwards compatibility. Since the absence of a base essentially meant building for an Ubuntu 16.04 target and this target has entered ESM, it is also being removed and another reason for the version bump to 5.0. Publishers needing continued support for base: core will be using the 4.x track.

There are various commands that leverage this re execution logic.

Convert use of core warning in hard error

A warning was introduced in Snapcraft 4.8.1, this should now be appropriately adapted into an error.

Snapcraft 6.0

  • Release date: 2021-09-21T03:00:00Z
  • Status: In Progress
  • Call for testing: In Progress

This release’s storyline is a bit of a mix, many threads to follow.

The theme is all about making Snapcraft easier to use inside an Enterprise with features like offline mode and use of LXD by default.

The gaming extension comes into play to solve most of the hassles around the nuances required to set up alsa to correctly work within the context of a snap (which most games use) and other bits and pieces (i.e.; common libraries).

Additionally, reusing some of the newer components that have spawned out of Snapcraft’s core, such as craft-providers (the component that handles Multipass and LXD environments). Together with the migration of Snapcraft to core20, Snapcraft will internally benefit from an up to date technology stack.


Migrate Snapcraft to use craft-providers

This task has been postponed.

Craft Providers is the newer logic around creating build environments, documented on Code is hosted at

  • Specification:

Gaming extension

This task has been postponed.

Bytecode re compilation for conflicts between parts

This task has been postponed.

Debsource plugin for parts

This task has been postponed.

LXD by default when the host is Linux

This task has been postponed.

snapcraft --offline

Allow for passing in --offline to any of the life cycle commands to ensure no update requests are made on the network. Failing as soon as possible if there is an inconsistency. For the case of build providers, analysis is needed to see if the default network routes can be removed completely to ensure things out of Snapcraft’s control (such as network dependent commands inside the build systems)


Migrate Snapcraft’s base to core20

This migration is tricky as moving to core20 means dropping i386 support, this is the reason for the major version bump.

  • Specification:

That’s a really nice writeup!

Is there any discussion/documentation around the gaming extension you can link to? I’m personally interested in it from maintaining some gaming snaps. I’m presuming that the ALSA magic is setting up $ALSA_CONFIG_PATH and libasound2-plugins, but I’d be interested in seeing what else is in there.


The specification has not been written up yet, the spec proposal will be here on discourse when it comes (and linked in this post), but if someone else wants to draft one for discussion that is also something to look forward to :slight_smile: