> 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.