Welcome snapcraft 2.31

Hello snapcrafters!

We are pleased to announce the release of snapcraft 2.31:


This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:

New in this release



The move to the new argument parser caused the CLI to regress slightly by duplicating error messages in some circumstances and changing how it handled arguments to the snap command. That has been fixed in this release.

Resume snap downloads

Snapcraft supports downloading the core snap when building classic snaps. This release adds the ability to resume the download of that snap if an error is encountered when trying to fetch it. This feature is really used more in CI than anywhere else, particularly in our own tests, where downloading the snap fails all the time with connection resets. This change did not help quite as much as we’d hoped in that situation, but it’s nice to have nonetheless.


The git source-type was using --remote when updating submodules, which updated each submodule rather than using the commit recorded in the super project. That’s fixed in this release.

Better build-packages asset tracking

In this release, build-packages asset tracking has been extracted into a project-wide state area instead of being tracked individually in each part’s state. This fixes some awkward behavior when attempting to walk the dependency tree.



The qmake plugin previously required one to specify the Qt version being used. In this release, it’s started defaulting to Qt5.


Support has been added for cross-compiling Go parts by using snapcraft --target-arch=<arch>. This supports use of cgo as well. We’re currently working on support for cross-compiling with stage-packages– if you’re using stage-packages, please wait to use this feature. We’re implementing it in phases.


Larger Catkin projects often keep track of their components by utilizing one or more rosinstall files. This release adds support for those files to the Catkin plugin, allowing an entire ROS project to be built from a single file.

Store integration

Header change

This release changes away from using X-Ubuntu-Release to X-Ubuntu-Series for communication with the store.

Final notes

To get the source for this release, check it out on github.

A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums and the snapcraft channel on Rocket Chat. Please also feel free to file a bug.

Happy snapcrafting!
– Kyle and the team


I was expecting snap install snapcraft to work, but it looks like 2.31 is still only in the beta channel?

⟫ snap info snapcraft
name:      snapcraft
summary:   "easily create snaps"
publisher: canonical
contact:   snappy-canonical-storeaccount@canonical.com
description: |
  Snapcraft aims to make upstream developers' lives easier and as such is not a
  single toolset, but instead is a collection of tools that enable the natural
  workflow of an upstream to be extended with a simple release step into Snappy
  enabled system.
  - snapcraft
tracking:           beta
installed:          2.31 (233) 53MB classic
refreshed:          2017-06-09 02:00:21 +0100 BST
  latest/candidate: 2.29.1            (99)  53MB classic
  latest/beta:      2.31              (233) 53MB classic
  latest/edge:      2.31+git1.714425a (237) 53MB classic
1 Like

Indeed, as mentioned in the availability post linked above, you’re right, the snap is still in the testing phase. 2.31 is in the beta channel:

$ sudo snap install --beta --classic snapcraft
1 Like

This very much sounds like it has reached stable :confused: . It’s unclear what you’re announcing with this, and why availability is in a separate post. The first thing I want to do reading a software announcement is find out how to get it :slight_smile:

1 Like

That’s a fair critique. There are a few moving parts here:

  1. The actual release of snapcraft (assigning a version number containing a specific set of features/bugfixes). This is the 2.31 tag on github, and that’s what we’re announcing here. You could consume it directly if you wanted to run it in a virtualenv, for example.
  2. Once we actually make a release, we start the process of SRUing it back into xenial, yakkety, and zesty. This takes a while, which is why availability status is tracked on the status topic (the first link in the announcement). We could track that here, indeed I’m not sure why we’re not, but it doesn’t change the fact that depending on how you obtain snapcraft you’ll get it at different times (which is why we announce when we tag).
  3. The snap of snapcraft is still pretty new. Snapcraft behaves a little differently when snapped, and we’re still working out the kinks. That’s why it hasn’t yet reached the stable channel, although we anticipate that it will soon. Your using it will help!

To be specific, the work on the CLI changes did not cause the duplicate error messages but instead caused by a refactor on erroring for some other feature.

1 Like