More and more WGs tend to publish different versions of the same specification in order to reach the status of Recommendation as fast as possible. All the features that do not pass the REC-track requirements are moved to a different version of the specification so they don't prevent earlier versions from going forward.
From the publication side, each level is treated as a different specification, meaning there's no clear relationship between shortname-1 and shortname-2. This is confusing on several points:
See also the thread started by Tobie.
One way to solve the problem is to introduce new links that are clearly defined so people know what they can expect when they browse these links. We would add 2 new links pointing to the editor's draft and the list of the different versions:
However, the main question still remains: how can we identify the "stable" and "unstable" versions?
A few set of specifications may refer to a generic shortname. One example is CSS. Because there's no CSS3 or CSS4 specification, /TR/CSS cannot point to /TR/CSS3 or /TR/CSS4. Instead /TR/CSS maps to a snapshot that is updated on a regular basis by the WG. That snapshot gives some details about the current state of CSS and explains the different levels. This is something we intend to keep for specific cases.
New editions of existing Recommendations should be treated as a new level of the specification.
The edit in-place policy allows modification in case of "Some visible status updates, such as indicating newer versions" so we can add a deprecation note to the old stable specification (eg. html5).
The following examples show how the links would look like if we go with proposal 1 or proposal 2. As explained above, proposal 3 is a simple mix of both proposals.
With proposal 1:
With proposal 2:
With proposal 1:
With proposal 2:
With proposal 1:
With proposal 2: