The snapcraft CLI team has been working on some large features this cycle, including:
Using build VMs by default
Extensions instead of remote parts
Plugin API changes to get rid of wrappers
Put simply, these features aren’t backward compatible with the way the snapcraft CLI works today. Our solution to date has been hiding these new features behind the use of bases: using a base? Then you’re using build VMs, etc. However, there are a number of issues with this approach.
First of all, having all these conditionals makes for a fragile code-base, and creates a non-trivial testing and maintenance burden. Second, it’s not particularly user-friendly. If folks decide they want to start targeting core18 with their snaps, they’re suddenly slapped in the face with the backward-incompatible changes and need to change various parts of their project to continue, while still using the same snapcraft release.
Proposal
Instead of maintaining essentially two different versions of the snapcraft CLI in the same codebase, we propose that the introduction of build VMs makes for a perfect time to introduce snapcraft v3. Specifically, Snapcraft v2 would continue to work the way it does today, and not support bases nor build VMs. Feature work would stop on v2, although bugfixes will of course be backported. Feature work would continue on Snapcraft v3, which would only work with bases and build VMs.
How will this work, specifically? We propose creating both a 2 track as well as a 3 track. The latest release of each will be available within those tracks, and latest will continue containing v2 releases until such a time that the vast majority of users have migrated to one of the major tracks (or epochs are released, allowing us to release v3 into latest without breaking existing users). When attempting to use bases on snapcraft v2, it will direct one to use snapcraft 3.x instead. Note also that the deb will remain at v2. Given that build.snapcraft.io today has no knowledge of bases today, the proposal is that v3 is used when the base keyword is found in snapcraft.yaml.
This allows us to forge ahead on new features quickly without fear of breaking existing users while still providing for a healthy v2 maintenance plan. It’s also more user-friendly in that existing users will need to make a decision to switch major versions of snapcraft in order to use bases, which provides the messaging that there are larger changes involved.
My only concern with using tracks to distribute the two snapcraft versions is that it will be inconvenient for developers who manager multiple snapcraft projects. It’s unlikely that the developer will manage to upgrade them all simultaneously, and they might need to go back to the old snapcraft to put out a maintenance release of their package while upgrading it on edge. So there is going to be a time period when they need both tools.
Would tracks require them to continually reinstall the tool as they change context, or would it be possible to have both versions installed simultaneously?
Using containers by default would be great for ensuring consistent builds across environments. However currently as far as I know it is not possible to adjust the repositories used by container builds like you can when building on the host system. This will be an issue for me as I currently need to add armhf repos when I am cross compiling.
I think that it’s a good idea to make this Snapcraft 3.0.
However, I’m a little concerned about the ability to integrate Snapcraft into larger systems.
For example, if Snapcraft always requires a VM, how is it going to run in the environment set up by Koji? Koji sets up chroot/nspawn container environments using Mock, and those things wouldn’t have the ability to create VMs. They may not necessarily be running on VM-capable environments either.
For all the flaws of Snapcraft v2, at least I could see a path of using it similar to how we use rpmbuild, appliance-creator, and so on.
I think it’d be key to factor that into the design of Snapcraft v3 in order to facilitate broader adoption across various release engineering tools.
Thanks for bringing this up, we have however, thought about that situation and it is another reason to cut a new release.
We intend to have a toggle on the snapcraft command to enable destructive mode, which means, build on this host, the naming is enough so the casual user does not run snapcraft locally and get a bunch of things installed onto their system, this is the other reason for going with 3.0.
