The problem I have with version numbering is that it creates state that every
implementation must know about in order to support. Fundamentally, versions
are used to represent two different entities:
. mostly-compatible differences (= a clue that some minor extension may be
present)
. incompatible differences (= don't even try feeding it to an older reader)
Suppose I have a "GIF" reader that knows about version 1. I get something
that is called "GIF version 2". I do not know if it is reasonable to feed it
to my version 1 reader and hope for the best.
What is worse, the presence of a version numbering mechanism virtually begs
for a proliferation of versions for extremely minor changes/extensions. This
makes things almost totally open-ended!
I would support a versioning system -- essentially a ;VERSION=n attribute --
if and only if it was limited to the first type of versioning. That is, to
differences that an unaware reader can reasonably ignore and hope for the best
in displaying it.
Anything that is essentially incompatible -- a "don't even try if you don't
know what this version is all about" sort of thing -- should be done by means
of a new subtype name. If "GIF version 2" can not be processed by a GIF
reader then it is no longer GIF, but rather is GIF2.
This has as a side effect the discouragement of a proliferation of
incompatible versions of a type, since it requires the creation of a new type
in each case. I consider that a feature.