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