Releasing new versions

[shoogle]

@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?

[probonopd]

That's a very structured approach but I fear that we can't keep up with juggling 3 versions in parallel; initially I'd like to use draft.md as the version "being worked on" which is eventually released (branched from). If that proves to be insufficient, I'm more than happy to reconsider.

[shoogle]

I think that's fair enough for the time being because we obviously have a bit of catching up to do while we work on "Version 0". In time though, I would see "future.md" as the working document and "draft.md" just as something to move things to once we seriously plan to implement them.

The idea is that "future.md" shows the direction we would like to go in, and we don't scare developers by constantly changing "draft.md" making it seem like huge changes are just around the corner.