Releasing new versions

@probonopd many thanks for taking up my suggestion to have a formal specification. What do you think of this as a release strategy:
1. We release a "Version 0" as soon as possible that describes what AppImages are already (i.e. everything that AppImageKit gives you automatically today), plus some **OPTIONAL** features that many AppImages have (like a remote update URL in the Volume Descriptor).
2. Once v0 is released we immediately begin writing ideas down for future versions in a "preview.md" or "future.md" file to let developers know what we are seriously considering doing at some point in the future, but may not be ready to do right now.
3. Once we have a few ideas in "future.md" we move the more easily achievable ones to "draft.md" for Version 1 and begin work on implementing them within AppImageKit.
4. A Draft only becomes a Version once it has been fully implemented in AppImageKit.

| file | usage |
| --- | --- |
| future.md | Ideas that we want to include in the spec but are not yet ready to do so |
| draft.md | Things that are very likely to be in the next spec and we are working on now in AppImageKit |
| latest.md | The current specification as implemented in the latest stable release of AppImageKit |

Perhaps AppImageKit releases should be tagged and versioned to match the specification? Perhaps we should start recommending packaging against the latest stable release of AppImageKit rather than the latest commit? Any thoughts?