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.

Janelle Jenstad, Associate Professor, Department of English, University of Victoria

Director, Map of Early Modern London; Director, Linked Early Modern Drama Online

Co-Coordinating Editor, Digital Renaissance Editions and the new Internet Shakespeare Editions

Co-Applicant, The Endings Project

Email: jenstad@uvic.ca, lemdo@uvic.ca, or london@uvic.ca

From: Tei-council <tei-council-bounces@lists.tei-c.org> On Behalf Of Bauman, Syd
Sent: April 21, 2022 1:45 PM
To: TEI Council <tei-council@lists.tei-c.org>
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:

dispose of the refrigeration period
generate release branch ~1–2 weeks before release
build all release products that can be built and checked without actually being on the server — this includes the release notes
everyone spends time checking the products
only serious bug-fixes get merged from dev to release, and only by a release tech
any time a bug-fix is applied, all products get re-generated and tested again
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.