There are a number of situations where snapd needs to notify a snap that something has happened. For example, when a snap is upgraded, the snap may need to run some sort of migration on the previous version’s data in order to make it consumable by the new version. This is possible today, but it requires that the snap be smart enough to realize that it’s running on old data, and there’s no way for the snap to inform snapd that the upgrade failed. A new global section should be added to the `snap.yaml` (alongside `apps`), called "hooks." To continue with the example of an upgrade, such a section would look something like this:     hooks:       upgrade: # Actual name TBD         plugs: [network] The name of the hook ("upgrade" in this example) directly corresponds to its purpose, and must be one of the yet-to-be-determined hooks supported by snapd. It also directly corresponds to the file name of the hook executable, which by convention is to be placed into the `meta/hooks/` directory within the snap. Similar to apps, the hooks may utilize plugs in order to extend their capabilities. Note that if the hook doesn't require any plugs, it doesn't need to be present in the YAML at all (i.e. its presence in `meta/hooks/` is enough for snapd to know it should be run). Hooks may be written in any language that is available to the snap. They will be called with no parameters-- if hooks need information from snapd it can be obtained via a yet-to-be-determined API call. If the hook returns a non-zero exit code the hook is considered to have failed, and snapd will take remedial action accordingly. The action taken depends on system choices made for the hook being run. Potential actions are retrying, or failure which would cause the whole change to be undone per existing semantics.