Add back language about substantive changes invalidating previous review

[sideshowbarker]

Previous versions of the Process doc contained language about substantive changes being changes that “invalidate” previous review or implementation of a spec. But somewhere along the way, that language got dropped. But it’s very useful language which helps to make things more clear to readers. So, the patch in this PR adds that language back.

---

Preview | Diff

[frivoal]

I tried to look for when that wording was removed, to see if we can learn anything about the context of that removal, but I could not find this wording in any prior version of the Process, nor any other wording that used the word "invalidate" in that context. Can you point to which version(s) of the Process had such language, and to what language was used?

[sideshowbarker]

Can you point to which version(s) of the Process had such language

It was at https://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs and https://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs in the 2004 and 2005 versions of the Process doc — in requirement #2 of the General Requirements for Advancement subsection in the W3C Recommendation Track Process section.

As far as I can tell, the next version of the Process doc after the 2005 version was the 2014 version at https://www.w3.org/2014/Process-20140801/ — and the language doesn’t seem to appear at all in that version.

So I guess that means the language got dropped between the 2005 and 2014 versions.

[dwsinger]

I think it was re-written and now doesn't use the word "invalidate":

changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation.

and the definition of changing conformance later. I'm not sure that that "invalidate" is the right word here. (I don't recall this change, though, sorry).

[frivoal]

I feel the point expressed in this PR is valid, and fairly well phrased, but at the same time it seems redundant with existing phrasing (notably what is covered in the definition of class 2). Should we add it as a note? Should we keep the Process short and not add it? Can we rephrase other parts to make that point clearer without making the document longer?