Evolution/Versions

(Originally from [Evolution of the web -- versions]

The W3C TAG and others have written extensively on versions, versioning, version numbers, and the relationships between specifications.

This page is still a placeholder for bringing together the issues:

compatibility (backward, forward)
the relationship to version, edition, errata, corrigem
the debate about using and assigning version indicators, in-band or out-of-band
the HTML DOCTYPE controversy
HTML5 vs. HTML forever,
JavaScript eversion numbers

Considering factors of deployment, motivation to 'reverse engineer', the 'quirks mode' problem, race-to-the-bottom

Also 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.