Determining the set of snapd capabilities

[Joseph Rushton Wakeling]

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