Versioning AppImage components

[TheAssassin]

One design goal of this new type is to provide reliable and verifiable versioning. There's several suggestions how to handle this. Basically, we have to decide how to put version numbers on the actual components of an AppImage:

• the runtime (ELF executable header)
• the new AppImage header (metadata format); I've called its versioning "revision" so far
• the AppImage type (e.g., 3 for the upcoming one, 2 would be the direct predecessor)

We can version them each separately, requiring 3 different versioning approaches, or we can use combined version numbers for some or all of them.

Here's a short summary of what I think was suggested so far in #1, where this has been discussed before by @5pacetoast and me primarily.

We've concluded that the runtime ELF header is independent from the actual AppImage format. Any binary which can read the AppImage header should be used interchangeably (i.e., I can use either runtime, provided that runtime supports at least the version of the AppImage header).

The question is if we have to separate AppImage type and AppImage header revision. I personally think we do not have to overly complicate this. Whenever we make really breaking changes, we can bump the AppImage type number. This is IMO rather unlike, though. Therefore I propose to strongly bind the AppImage header to the AppImage type.

There might be situations in which we have to e.g., replace attributes due to security issues, where you can either remove the old attributes and introduce new ones. This breaks the backwards compatibility, however, so my approach would always be to just abandon the attributes (but keep them in the header), and append the new ones. This way, older software can still use the new AppImages. Since the old, broken fields are empty, the features based on them should just not be used by the old software.

If we decided to go for the "breaking" approach, we could have situations in which AppImages of the same type cannot be used by software claiming to support a certain type. That's an inacceptable UX to me. It's a "sub-typing" of AppImage, where we'd have a 3.1.x.y kind of format and a 3.2.x.y (the former uses header format 1.x.y, the latter header format 2.x.y) instead of one type 3 that will be easy to support forever. And if we really have to make a breaking change, we need to signalize that clearly to developers and users of applications which deal with AppImages.

@5paceToast do you have any idea how to maintain the "type 3 means type 3" and avoid a "different header major versions create subtypes" UX?

That said, the header revision does not have to be a scalar number. I don't see the major benefits to using e.g., a minor and a patch version as of now, but adding a second scalar number to the version is an easy task.

[CosmicToast]

@TheAssassin what if we tie AppImage type and AppImage header?
If there is ever to be a "Type 4" that changes the overall format, I would imagine there will still be an AppImage header, and thus the major version could be bumped on it.
If the AppImage header is removed in its entirety, that is fairly unambiguous as well.

So in short:
There is a runtime, a header, and a payload.
The header is versioned (semantic).
Payloads know to be compatible against MAJOR.MINOR versions of a header, with patch being there for debugging purposes.
If Major is ever bumped, the runtimes need to be updated.
The version of the runtime is entirely unrelated, and it may contain a piece of information like "can handle header versions 3.9.X".