Hi Syd, Since "backwards-compatible" is essentially undefinable, especially for TEI, where the prose is generally held to trump the specification, I also favour "based on", and a general understanding that we-know-what-we-mean. Major version = we did something cool/different/worth celebrating, minor version = the every-six-months scheduled release, point-release = oops we screwed up and this can't wait for the next scheduled release. Cheers, Martin On 2021-02-09 12:28 p.m., Bauman, Syd wrote:
At the VF2F we apparently discussed PR 1996 (which implements one point of the discussion on issue 1993). Does anyone remember what, if anything, I said about it? My suspicion is I was making tweaks for 2032 at the time, and did not realize y’all were accepting the idea that TEI/@version (et al.) is a “version number following the Semantic Versioning Specification”. Because it is not.
This would have serious (albeit extremely rare) side-effects in processing, because it means we would be obligated to drop anything from a ‘+’ on (i.e., the build metadata) when ascertaining order of precedence.
Much more importantly, it means that we would be obligated to change our system of changing the MAJOR and MINOR portions of the version number. (The PATCH bit would still be updated only for backwards-compatible bug fixes.) We currently update MINOR every new release (roughly every 6 months), and only update MAJOR if and when there is a significant change in functionality (e.g., switching to PureODD). If we adopt SemVer, we would be obligated to change MAJOR whenever any backwards-incompatible change occurred, no matter how small.
Furthermore, we would have to define backwards-incompatible. Obviously a change (even a bug fix) that changes the schema such that a document that was valid before the change is invalid after it is a change that requires a bump in the MAJOR portion in the SemVer system. But what about the reverse, a change that allows a document that had been invalid to be considered valid? (E.g., adding "PostScript" to the value list of @scheme in att.styleDef.) Seems to me that is backwards-incompatible too, just in a different way. (The schema no longer catches the same “error” it used to.)
Conversely, of course, we could use the idea that SemVer refers to the incompatibility of the API, not of the schema, to decide not to bump MAJOR for incompatible schema changes. But if the version number is about the API, what API is it about, and what does it have to do with our release system and schemas?
I think all of this can be avoided by just saying “based on” rather than “following” the Semantic Versioning specification. (Note that in either case it should be capitalized and have a reference in the bibliography to the spec https://semver.org/ that we don’t follow but maybe will say that we do.)
If y’all really think we really should say we are following it, I will accept the majority opinion. That said, you should not vote in favor of “following” until you have actually read the SemVer https://semver.org/ spec.
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre