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
