- Tei-council - lists.tei-c.org

semantic version conversation
by Bauman, Syd 15 Feb '21

15 Feb '21

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.

5 9

keep Subversion version # capability? On stupidity
by Bauman, Syd 13 Feb '21

13 Feb '21

Hey all. Two things. First just wanted to clarify that when I said “because it’s stupid” in reference to <text> as a direct child of <teiCorpus>, I was trying to express that it was inappropriate and careless of us to ever let <text> slip into the content model of <teiCorpus> in that position (which happened in 2016-02). I am (as y’all can probably tell) somewhat annoyed with myself for not noticing this as a problem when it came up then. I was not calling users (like Martin and Janelle, among others) who make use of this perfectly valid facility stupid. My current annoyance, though, is some horrible code. Thus I want input on what to do with P5/repodate.xml. This is an untracked file generated by the Makefile during the P5 build process and read by the P5/Utilities/expand.xsl program. That program changes the <?insert date?> PI found in P5/Source/guidelines-en.xml (and in P5/Source/guidelines-fr.xml) and thus in p5.xml into the date the GLs were built, and changes the <?insert revision?> PIs into the git commit number, etc. This whole system is made quite a bit more complicated by the fact that the code is designed to work whether the version control system we use is Subversion or git. My instinct is that it is no longer useful to maintain the code that worries we might be using Subversion rather than git. We have not been using Subversion for roughly 5 years,[1] and I do not see us ever going back to it. Sure, GitHub the service is a company and may fold, but git the command is not going away. Something better may come along, and we may switch in the future, but that means re-working all this code, anyway. The only reasonable concern that floats through my tiny brain is that maybe we need this code in case someone uses the current build system to try to generate a very old copy of the Guidelines that dates back to the pre-git days. But I do not have any reason to believe that either anyone would use the modern Makefile to build an ancient copy of the Guidelines (you would use the build system that came with that revision), or that there would be any hope of success even if this code for handling Subversion revision numbers was left in place. So does anyone think we should leave the Subversion code in there? Going once … P.S. Given that we are in the refrigeration period, I will be doing this in a separate branch and leave it to others whether to merge it before or after release. It should have absolutely no effect on the output at all. (And if anything goes wrong, would be very easy to spot by just checking the output of PIs.) Notes [1] My vague recollection is that the changeover from Subversion in Sourceforge to git in GitHub was masterfully handled by Peter Stadler in 2015 or 2016.

3 4

Next VF2F: May 7 and 8
by Scholger, Martina (martina.scholger＠uni-graz.at) 12 Feb '21

12 Feb '21

Dear all, Our next virtual F2F meeting is on May 7 and 8. As last time, the North American Group starts on Friday at 12am PST / 3pm EST (3 hours); the Europeans continue on Saturday morning at 9am BST/10am CET (3 hours); the full Council meets on Saturday 6am PST / 9am EST / 2pm BST / 3pm CET (4 hours). Please have a look at the google calendar to check the meeting times. Best, Martina

1 0

Council call in 40 minutes
by Scholger, Martina (martina.scholger＠uni-graz.at) 11 Feb '21

11 Feb '21

Dear all, Our call starts in 40 minutes. Agenda: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

1 0

Re: [Tei-council] Mr. Jenkins is ignoring me
by Bauman, Syd 10 Feb '21

10 Feb '21

Thank you, Peter! (Why did I not see it in the dashboard? Why did I miss the build failure locally? Hmmm...) ________________________________ seems it’s there at https://jenkins.tei-c.org/job/TEIP5-Test-dev/680/ The build has been kicked off due to your commit but failed, hence the subsequent jobs have not been started at all.

1 0

Mr. Jenkins is ignoring me
by Bauman, Syd 10 Feb '21

10 Feb '21

Attn: Peter & Martin I committed to dev branch at 20:50:00 localtime (± 6 sec), commit #9d8122417ee2ec8d05f979bf920f98069586817a. That was over 2 hours ago, and yet neither Jenkins[1] seems to have noticed. Worse, one of them seems to have kicked off a build at roughly halfway between then and now, but it does not list my commit as its reason for existing. Snif! What is going on? — Syd “I’ve been ghosted by a CI server!” Bauman [1] https://jenkins.tei-c.org/view/TEI%20dev/ https://jenkins2.tei-c.org/view/Dev%20branch%20jobs/

2 1

Re: [Tei-council] Next Stylesheets meeting
by BERMUDEZ SABEL Helena 09 Feb '21

09 Feb '21

Hello! No issues with the proposed date. Best, H. Helena Bermúdez Sabel Chercheuse FNS senior Institut des sciences du langage Université de Neuchâtel ________________________________ From: Tei-council <tei-council-bounces(a)lists.tei-c.org> on behalf of Scholger, Martina (martina.scholger(a)uni-graz.at) <martina.scholger(a)uni-graz.at> Sent: 08 February 2021 18:08:07 To: tei-council(a)lists.tei-c.org; Martin Holmes; Nicholas Cole Subject: [Tei-council] Next Stylesheets meeting Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

6 5

PDF build with Japanese
by Martin Holmes 08 Feb '21

08 Feb '21

Hi all, The ruby stuff is now merged into the repo, and I've spent a good few hours now trying to get the PDF to build properly. It dies with this error: ! LaTeX3 Error: The key 'fontspec-opentype/...' is unknown and is being (LaTeX3) ignored. which is something to do with xml:lang='ja' appearing in the source. At one point I got it to build, but without the Japanese language attributes, the characters just come out as square boxes. Can anyone who knows more about LaTeX than me suggest anything? I don't really want to go round removing xml:lang attributes just to get past the PDF problem, but I don't know what else to do at this point. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes(a)uvic.ca

4 8

Next Council call: Feb 11
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, This is the preliminary agenda for our next Council call on February 11 at 11am-12:30pm PST/2pm-3:30pm EST/7pm-8:30pm GMT/8pm-9:30pm CET: https://docs.google.com/document/d/1mnUQtzMFTpPfUwoBQX2yo4g_sWeBrHBG4Z2myRK… The zoom link is in the google doc. Best, Martina

2 1

Next Stylesheets meeting
by Scholger, Martina (martina.scholger＠uni-graz.at) 08 Feb '21

08 Feb '21

Dear all, The next Stylesheets meeting is scheduled for February 25, the day of our release. I propose to postpone the meeting to March 4. Please let me know if this works for you. Best, Martina

1 0