And W3C pages on this.
This section would (a) note the issues of compatibility (backward, forward) and the relationship to version, edition, errata, corrigem; discuss the debate about using and assigning version indicators, in-band or out-of-band, the DOCTYPE controversy, the HTML5 vs. HTML forever, JavaScript, etc. and summarize the various pros and cons against the considerations of widespread deployment, motivation to 'reverse engineer', the 'quirks mode' problem, race-to-the-bottom) See [IAB-extensions] section 4.1 for version number discussion. Modes (quirks mode, near standards mode) in receivers attempting to adapt to evolution by mis-using version indicator. History of bad versioning practices?)
Specifications have versions. most languages used on the web don't have versions, in that most implementations of readers of the language are written to try to adapt whatever data they get to they get to whatever the implementors believe is the best they can do to satisfy user's expectations, as well or better than any other implementation, subject to the internal constraints and architecture of the implementation. In these situations, where features are implemented incrementally and are not orthogonal extensions, using a version indicator to distinguish author's intent is unacceptable. The version indicator at best gives you some (but not a very good) idea of who to blame.
Implementations have versions: Implementations have versions, and, in particular, what authors of content might want to know (or select among) is what set of language or protocol features (or versions of those features) are supported (correctly) by the receiving implementations. This leads to doing content-negotiation based on User-agent.