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.