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.