Releases & locking snapcraft “parts” at specific versions

[DriesOeyen]

Are there currently any plans to introduce public-facing numbered releases of this snap, for example through GitHub releases or regular Git tags, and within those releases lock all the various parts listed in snapcraft.yaml to particular versions of that dependency (by tag or commit reference)?

This would be super beneficial for reproducibility of builds of Snapped CUPS, something I’m particularly interested in (I dabble in building the CUPS Snap myself) and generally seems like good hygiene from a technical perspective.

(This was originally posted in September 2022 as a comment to one of the monthly OpenPrinting news posts written by @tillkamppeter. I really appreciate reading these every month, thank you for taking the time to write them! Unfortunately Disqus had marked my comment as spam and I failed to notice until now... so I'm trying again via GitHub Discussions. Looking forward to hear your perspective!)

[tillkamppeter]

First, I actually intend to version all the Snaps, but only when all the underlying components are versions, which is currently in the works. They are already at least beta versions now. When they have run through their first rounds of distro packaging with the usual bug reports and fixes of that phase, I will start to version the Snaps (probably when they all have gotten RCs, Release Candidates).

Second, I never received any Disqus comment on any of my News posts (generally not on any posts or articles on OpenPrinting). I was already fearing that nobody reads them. Perhaps everyone gets everything rejected as spam. Thanks a lot for your report and letting me know that you like my News posts. It is like a talk on a conference, it is not only important to give a talk (therefore I do not accept if the organizers ask me to send a pre-recorded talk), but also the questions and subsequent hallway sessions the talk generates, same with the News posts.

[DriesOeyen]

First, I actually intend to version all the Snaps, but only when all the underlying components are versions

Wonderful, that's great to hear and this approach makes sense. 👍

At the same time, I still feel like there's an easy-win opportunity to improve on the build reproducibility aspect – even in this stage, before all underlying components are fully versioned. Looking at the current state of snapcraft.yaml, we're already more than halfway there: 6 out of 11 parts are either part of this repo (under source control) or pinned to a specific version/tag through various means. The ones that aren't are:

• snapd-glib
• libcupsfilters
• libppd
• cups-filters
• cups-browsed

These 5 parts currently pull in whatever happens to be the HEAD of master at build time.
But looking in a bit more detail:

• snapd-glib could be a simple oversight, since what's currently on master appears to correspond 100% to the 1.63 release. So this could theoretically be pinned as source-tag: 1.63
• The other 4 parts are OpenPrinting components. I understand the case for not working with releases/versions/tags here yet, but build reproducibility could still be achieved by adding a source-commit definition referencing the commit that you were working with at the time of implementation. Based on what you write in the OpenPrinting News posts, I understand this is often simply the HEAD of master. Applying that today, it boils down to adding the following one-liner to each of the 4 parts:
  • libcupsfilters: source-commit: 5fd5abc6d8c668225988138d6b3bb98e49486727
  • libppd: source-commit: 770116ffbced0f20d3a23379220354e1793918d3
  • cups-filters: source-commit: 17316a325cd3870c9457ef1d0a1d213b80c80680
  • cups-browsed: source-commit: bdc5ae945ed0725e7a3806de7425c88a1e97834e

The advantage to doing this is that a build of cups-snap that works today is basically guaranteed to still work next week, next month, next year, and so on. It extends the benefits of source control from "just the code" to "code + build process".

The obvious drawback is that you'll have to keep those commit references updated as you push forward with moving cups-snap and its various components towards stable releases. However, I can see on the Snap Store that you're regularly rebuilding the CUPS snap anyway, presumably to keep up with your work across the stack... so perhaps it's not too much of a detour?

Ultimately, it's up to you to decide if this is an effort that's worth your time. If it's not, I understand and I can easily just do this myself in a fork for personal purposes. But I imagine the CUPS snap is now close to (or maybe has already exceeded) 1 million users, so I imagine I'm not the only one in that install base that's interested in building this snap myself. 🙂