Hi Robie, In essence, re-execution is what enables us to move at a different pace than distributions which is considered an important part of the Snapd value proposition.
``` The SnapD value proposition is to allow installing robust software that can move at a different pace than distributions, in a rolling release model. In order to fulfill this, it needs to provide a security-maintained, consistent and up-to-date runtime environment for them across distributions and distribution versions. ``` At the current cadence of approx 2 months, with significant effort, we just about manage to keep up on the SRU side. Strictly speaking this is not required unless we touch very specific service related areas which happens relatively infrequently. In this situation, re-execution makes the latest Snapd available also for Ubuntu releases that is outside of standard maintenance. If we increase the cadence further -- which is the longer term goal -- it could make sense to do SRU releases at a slower pace. Re-execution would then ensure that feature and fix delivery remains unaffected by that slower SRU pace. ``` When the first snap is installed through the snapd deb, the snapd snap itself is also installed, and the deb then re-executes into it. The snapd snap is kept up to date through auto-refresh, ensuring that snapd always runs with the latest features and fixes, and maintains consistency across Ubuntu releases regardless of the host distribution’s update cadence. ``` We have on multiple occasions also run into deb specific issues e.g. due to host AppArmor, where re-execution enabled us to continue with the release. Overall, I believe its fair to say that re-execution has a very solid track record. -- https://code.launchpad.net/~ernestl/sru-docs/+git/sru-docs/+merge/493382 Your team Ubuntu Technical Board is requested to review the proposed merge of ~ernestl/sru-docs:update-snapd-exceptions into sru-docs:main. -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
