Hello snapcrafters! We are pleased to announce the release of snapcraft `2.27`: https://launchpad.net/snapcraft/+milestone/2.27
This release is now available to users on Xenial Xerus, Yakkety Yak and Zesty Zapus. The pretty version of these notes can be found on https://github.com/snapcore/snapcraft/releases/tag/2.27 # Contributions This release has seen some contributions from outside of the snapcraft core team, so we want to give a shout out to these folks, here's a team thank you for: - Colin Watson - John Lenton - Kit Randel - Loïc Minier - Marco Trevisan - elespike # New in this release ## Faster iteration This release brings in many features to speed up development and iteration, the biggest under the covers improvement is caching of `stage-packages` works correctly again succesive pull steps including a repeated set of stage-packages will be a breeze. The other improvment is that delta uploads are now possible, it is currenly disabled but can be toggled by a feature flag in the environment, just set `DELTA_UPLOADS_EXPERIMENTAL=1` and enjoy the benefits. The tentative plan is for this to be the default in snapcraft 2.28 ## classic confinement Improvements have been made to the experimental `classic` confinement build setup to be more robust and reliable. These improvements allow to build `classic` confined snaps that work across a wider set of OS releases (particularly those with differing glibc versions). An early adopter of this work is *conjure-up* which now sports Trusty Tahr support. Learn more about conjure-up by visiting http://conjure-up.io/ ### python plugin The python plugin has also received some attention with regards to `classic` confinement. Most importantly it now does not leak any variables specific to the plugin into the environment. Another improvement that has been made is that the plugin is now capable of detecting already staged interpreter instances and use that instead of providing one itself. This allows one to choose their own interpreter (which is important for classic confined snaps until the core snap implements use of `--library-path` for `ld`). Making use of your own interpreter is really easy as it uses the common language already implemented in snapcraft (the plugin is just now smarter), here's a snippet: ```yaml parts: my-python-app: source: ... plugin: python after: [python] python: source: https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz plugin: autotools configflags: [--prefix=/usr] build-packages: [libssl-dev] prime: - -usr/include ``` And with that you get to use python 3.6.0 in your snap! ### CI builds Previous to snapcraft 2.27 it was not possible to build on non `snapd` enabled environments as the core snap needs to be available on the system where the `classic` confined snap is to be built. From this version onwards it should be possible to build `classic` confined snaps either with `cleanbuild` or Launchpad builders as snapcraft is hinted about the environment and sets up `core` accordingly. ## Building on other `lxd` remotes A simple but useful feature is offloading builds to different instances, with that in mind one can now offload `cleanbuild` executions onto other `lxd` remotes. It is as simple as ``` snapcraft cleanbuild --remote my-remote ``` To create `my-remote` just follow the setup instructions on https://linuxcontainers.org/lxd/getting-started-cli/#multiple-hosts ## Setting up environment No more wrapper scripts just to setup on environment entry, this is now tied into an app entry in `apps`. Here's a quick example: ```yaml apps: vim: command: bin/vim environment: VIMRUNTIME: $SNAP/share/vim/vim80 ``` ## Releasing to channel tracks Releasing to tracks worked out of the box, this is a user experience improvement on the result one sees when trying do to so. If you are wondering what tracks are, here's a simple explanation, they are like a Long Term Support channel added to your regular stability level channels (i.e.; `stable`, `candidate`, `beta`, `edge`), this is useful for cases where some users need to stick to a major version number such as the case of `etcd` where some might want to stick to `2.3` while others are happy with tracking `latest` (which is an implicit track). From a snap developer point of view, here's how to push and release to `edge` on the `0.2` track, ``` $ snapcraft push hello_0.3_amd64.snap --release 0.2/edge Pushing 'hello_0.3_amd64.snap' to the store. Uploading hello_0.3_amd64.snap [==============================================] 100% Ready to release! Revision 3 of 'hello' created. Arch Track Series Channel Version Revision amd64 0.2 16 stable - - candidate - - beta - - edge 0.3 3 ``` And here's how you would release, ``` $ snapcraft release hello 3 0.2/beta Arch Track Series Channel Version Revision amd64 0.2 16 stable - - candidate - - beta 0.3 3 edge 0.3 3 The '0.2/beta' channel is now open. ``` ## Others For the full list of things available on 2.27 feel free to check https://launchpad.net/snapcraft/+milestone/2.27 # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.27 A great place to collaborate and discuss features, bugs and ideas on snapcraft is snapcraft@lists.snapcraft.io mailing list or on the snapcraft channel on Rocket Chat https://rocket.ubuntu.com/channel/snapcraft To file bugs, please go to https://bugs.launchpad.net/snapcraft/+filebug. Happy snapcrafting! -- Sergio and the team -- -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
