That release process sounds much more sane and responsible, even to a last-minute people (like me) who are pressure-prompted and highly tolerant of icky practices. J. Janelle Jenstad, Associate Professor, Department of English, University of Victoriahttps://journals.uvic.ca/index.php/scene/ Director, Map of Early Modern Londonhttps://mapoflondon.uvic.ca/; Director, Linked Early Modern Drama Onlinehttps://lemdo.uvic.ca/ Co-Coordinating Editor, Digital Renaissance Editionshttps://digitalrenaissance.uvic.ca/ and the new Internet Shakespeare Editions Co-Applicant, The Endings Projecthttps://endings.uvic.ca/index.html Email: jenstad@uvic.camailto:jenstad@uvic.ca, lemdo@uvic.camailto:lemdo@uvic.ca, or london@uvic.camailto:london@uvic.ca From: Tei-council On Behalf Of Bauman, Syd Sent: April 21, 2022 1:45 PM To: TEI Council Subject: Re: [Tei-council] Deprecation for ident changes? Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. But we do not aim "not to catch people out with a release" where "people" means "customizers", only where "people" means encoders. We have always conceded that new releases may require tweaks to customization ODDs. (And that is why we so strongly recommend that a customization ODD be tied to a particular release using an @source other than "tei:current". That way, the customizer only gets hit with changes when she changes the value of @source, and thus expects them.)

That means that the value of the bleeding-edge plugin as an advance testing mechanism is diminished. Again, not sure what could be done about that.

We need to stop the icky practice you describe of suddenly folding in ½ dozen PRs the day before release. I am beginning to think we need to revamp the entire release process. Among the thoughts jumbling around in my head (in near chronological order) are to: 1. dispose of the refrigeration period 2. generate release branch ~1-2 weeks before release 3. build all release products that can be built and checked without actually being on the server - this includes the release notes 4. everyone spends time checking the products 5. only serious bug-fixes get merged from dev to release, and only by a release tech 6. any time a bug-fix is applied, all products get re-generated and tested again 7. on release day all that happens is the release products are put up in the various places they go and an announcement is made I have not thought this out carefully, but the main points are to stop the frenzy of get-stuff-in-before-release many days before the release, and to separate the process of building the stuff from putting it up on the server by at least a few days. ________________________________ OUr LEMDO project got bitten by an unexpected change in the latest TEI release: we have a customization which deletes the Schematron rule which disallows nested ab elements, because we believe they should be nestable. However, the @ident of that rule was changed in the release, so suddenly our customization failed and a pile of files were suddenly invalid. No problem to figure out and fix, but it does show that changing an @ident should be subject to deprecation warnings if we aim not to catch people out with a release. I don't know how that could be done, though. We noticed a bunch of other unexpected changes too, and I was a bit surprised because I subscribe to the bleeding-edge Oxygen plugin so that I get plenty of warning of changes landing in the dev branches. However, I think what has been happening is that a lot of changes have been taking place in feature branches, and then languishing there until the last-minute mad scramble to land them in dev and release branches before the release date. That means that the value of the bleeding-edge plugin as an advance testing mechanism is diminished. Again, not sure what could be done about that.

because if I tie my customizations to a specific TEI release, I'm then only testing the Stylesheets dev branch, not the TEI dev branch, with the bleeding-edge plugin

True enough, can make it more difficult to use our own projects as guinea pigs. That said, I could well imagine $ perl -pe 's,tei:4.4.0,tei:current,;' < mdh.odd > mdh_current.odd && /path/to/bin/teitorelaxng mdh_current.odd

we have a set of mechanical diagnostics and milestones which all have to be completed, and we don't release until they're done, whatever the date is.

I would not mind trying that method, either. I think there is some advantage to knowing when the release day will be, but it may well be outweighed by having a “less fraught” release. 🙂 ________________________________ Oh, interesting; I hadn't really thought about that distinction. I'd be caught in the middle of that, because if I tie my customizations to a specific TEI release, I'm then only testing the Stylesheets dev branch, not the TEI dev branch, with the bleeding-edge plugin. I agree that the release process has never really been as clean as it could be. I prefer not to have a release date at all. For some of our projects, instead, we have a set of mechanical diagnostics and milestones which all have to be completed, and we don't release until they're done, whatever the date is. Perhaps the important date is the freeze date, and after that, everyone just works on fixing and checking until everything is perfect. Then you do the actual release in a less fraught manner.