I'm pretty sure we said precisely what you just said, that we can't wholesale adopt SemVer, but we can use something similar to and inspired by it. Hugh On Tue, Feb 9, 2021 at 3:36 PM Martin Holmes wrote:

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

...

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

On 2021-02-09 12:28 p.m., Bauman, Syd wrote: 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

I recall that most of the discussion revolved around whether using semver for the TEI Guidelines seemed appropriate, and we noticed that the SemVer specs themselves follow it. If they can do it so can we, we agreed. If adopting a subset of the SemVer spec is different from saying that "a TEI version number follows the Semantic Versioning Specification", then I agree that we should say inspired, or that implements it partially. Raff On Tue, Feb 9, 2021 at 5:40 PM Bauman, Syd wrote:

That (y’all agreed we cannot wholesale adopt SemVer) would be good to hear — but it would mean there is an error in the notes document, which says the opposite: “VF2F subgroup thinks that it is appropriate to say that a TEI version number follows the Semantic Versioning Specification.” Possibly the word “not” is just missing?

------------------------------ I'm pretty sure we said precisely what you just said, that we can't wholesale adopt SemVer, but we can use something similar to and inspired by it.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

[What is “lal”?] Yeah, given that the PR is not quite ready to be merged yet, I suppose this can has to be kicked down the road a bit. Since TEI users have been living with a nonsensical definition of @version for a decade and then an oddly restrictive one for a few years, another few months is probably not a big deal. I still really don’t see why the 4.4.0 schema should allow a @version that starts with anything other than “4.4.”. ________________________________ Not having heard a clear resolution, and with refrigeration and lal, I suppose PR 1996 moves to the next milestone? https://github.com/TEIC/TEI/pull/1996https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FTEIC%2FTEI%2Fpull%2F1996&data=04%7C01%7Cs.bauman%40northeastern.edu%7C818196d4fefc4e6d900608d8d0607760%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637488460035172470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VdjfxSjQKTzK2gz7WM1zb81Luh89H9TaPkPTmoQTqdw%3D&reserved=0

Ha! How embarrassing. Here I was wracking my brains … laugh a lot? Los Angeles Lakers? lightning activity level? (my brother-in-law was supporting firefighters in CA last year) latitude and longitude? Sigh. So yeah, unless someone wants to push hard on it, I think SemVer is 4.3.0 material. I am poking at 1981 today, too, but it may end up same fate, there. ________________________________ Sounds good. "lal" is a transposition error for "all"