On 19/02/17 12:21, Mark Shuttleworth wrote:
We have a nice mechanism to ensure that snaps which use newer capabilities don't end up on systems with older snapd's that don't support those capabilities, which is the 'assumes' keyword. This email is a proposal to make that usable.
This would be super-useful. Conversely, to what extent might it be possible to guide the package developer to a clear understanding of what capabilities a particular snap package assumes?
Step 3, introduce capabilities as 'beta-capability'
Sounds good. Working with classic snaps (for example) is obviously chasing a somewhat moving target right now. That was clear up front, but it would be nice to have it explicitly documented.
Step 4, announce new capabilities on the list In many cases, the existence of a new capability is meaningful for a large number of snapcrafters, lets share the beta documentation on the list when the capability lands in a --proposed or --candidate release of snapd+snapcraft.
Not just capabilities, but any breaking changes in behaviour. For example, while Sergio's support has been great regarding my recent experiences with snapcraft 2.27, I think I could have avoided taking his time if the release notes had mentioned that classic snaps would no longer see environment variables set in app wrapper scripts (and ideally, advised on the changes required to `snapcraft.yaml` files).
Step 5, nobody expects the Spanish Inquisition.
But I hope all snapcraft developers have comfy chairs? :-) Thanks & best wishes, -- Joe -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft