These are the release notes for Snapcraft 3.9.
For general details, including installation instructions, see Snapcraft overview, or take a look at Snapcraft release notes for other Snapcraft releases.
With snapcraft remote-build
, Snapcraft gains the ability to run a multi-architecture build process on remote servers, using Launchpad, directly from the snapcraft executable.
While remote build is still considered a preview in this release, it’s now fully accessible. Setup has also been simplified thanks to using HTTPS for git transport to push assets to the build server (removing the reliance on ssh).
For more details, see the documentation for Remote build.
Snapcraft will now attempt to avoid using unnecessary wrappers:
command-chain
is used to create an environment where snap --shell <snap-name.app-name>
can be run without the previously required environment setup.wrapper
file is detected, Snapcraft will work out whether it too can be avoidedA snap developer may inadvertently exclude a snap’s required libraries, either by filtering them out during stage
and prime
, through a script, or when libraries are linked against the host (amongst other reasons).
To help mitigate these missing libraries, Snapcraft creates an internal list of libraries that may be missing. Prior releases of Snapcraft would output this list as file names.
With this release, Snapcraft outputs the exact stage-packages
syntax to fix the missing dependencies. This can be pasted directly into the relevant part
.
Additionally, false positives from snaps that rely on the content
interface for their runtime have been reduced.
The core20 base snap (see Base snaps) is now a first class citizen in Snapcraft.
As core20 itself is still under development, plugin support will be added closer to its finalisation, and snaps built against its non-stable channel releases will be marked with a grade of devel.
Titles and versions are now extracted from AppStream data.
Consequently, both are now passed into the resulting snap.yaml where they can be used by the Snap Store on first push, or after a snapcraft push-metadata
call.
Internally, Snapcraft has fully migrated to core18. This allows for easier continued development and improved robustness.
Creating KDE application snaps is now even easier, thanks to a new KDE Neon extension.
This new extension integrates seamlessly with the KDE Neon content snap and builds on the foundations of the work done for the Gnome extension.
Documentation for this extension is being worked. See KDE Neon extension for further details.
The Gnome extension has been fixed when using only a snap name as the default provider, and launch performance has also been improved.
For documentation, see Gnome 3.28 extension.
The underlying implementation behind error message generation has changed, becoming more structured.
This allows for more specific messages about what may have gone wrong, why it went wrong, and how it can be fixed. Additional ancillary data, such as links to further documentation, is also presented for some of the error messages.
Prior to this release, using the ‘register’ command with snapcraft running under an interactive shell would generate an error message if the user was not logged in.
With Snapcraft 3.9, the user is instead prompted for their credential to continue with the registration. Similarly, when trying to push a snap, if the snap-name is currently unregistered, the user will be asked if they want to register the snap-name for the snap to be pushed, and then continue with the process.
The issues and features worked on for Snapcraft 3.9 are reflected in the following change list:
_get_project_directory_hash
methodall
option for --arch
Last updated 1 year, 4 months ago.