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
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council