Oh BLEEP! I failed to change the manual deprecation date from "2022-07-14" to "2022-10-21" on the "deprecate_altIdent_in_non-ODD_places" constraint specification (in file P5/Source/Specs/altIdent.xml). Now that we have published 4.4.0 with the “wrong” date I see 3 possible courses of action: 1. Leave things as is, and just act on the deprecation on 2022-07-14. Yes, that makes the deprecation period pretty short, but who uses `<altIdent>` anyway? 2. Do nothing in July. For the _next_ release (call it 4.5.0, as that is likely what it will be) reset the valid until date from 2022-07-14 to a date a few months after the 4.5.0 release. 3. Issue a point release (4.4.1) now that corrects the date to the desired 2022-10-21.
I would say #1. The worst that can happen is that one or two users will have to make a minor change in July, or will actually come up with a potentially valid reason for using altIdent somewhere it was never anticipated. Cheers, Martin On 2022-04-21 12:07, Bauman, Syd wrote:
Oh BLEEP! I failed to change the manual deprecation date from "2022-07-14" to "2022-10-21" on the "deprecate_altIdent_in_non-ODD_places" constraint specification (in file P5/Source/Specs/altIdent.xml). Now that we have published 4.4.0 with the “wrong” date I see 3 possible courses of action:
1. Leave things as is, and just act on the deprecation on 2022-07-14. Yes, that makes the deprecation period pretty short, but who uses `<altIdent>` anyway? 2. Do nothing in July. For the _next_ release (call it 4.5.0, as that is likely what it will be) reset the valid until date from 2022-07-14 to a date a few months after the 4.5.0 release. 3. Issue a point release (4.4.1) now that corrects the date to the desired 2022-10-21.
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day.
I'd say 1 or 2 are both acceptable. I lean towards 2 because it's slightly
more transparent, but also susceptible to this same oversight after the
next release...
Raff
On Thu, Apr 21, 2022 at 3:23 PM Martin Holmes
I would say #1. The worst that can happen is that one or two users will have to make a minor change in July, or will actually come up with a potentially valid reason for using altIdent somewhere it was never anticipated.
Cheers, Martin
On 2022-04-21 12:07, Bauman, Syd wrote:
Oh BLEEP! I failed to change the manual deprecation date from "2022-07-14" to "2022-10-21" on the "deprecate_altIdent_in_non-ODD_places" constraint specification (in file P5/Source/Specs/altIdent.xml). Now that we have published 4.4.0 with the “wrong” date I see 3 possible courses of action:
1. Leave things as is, and just act on the deprecation on 2022-07-14. Yes, that makes the deprecation period pretty short, but who uses `<altIdent>` anyway? 2. Do nothing in July. For the _next_ release (call it 4.5.0, as that is likely what it will be) reset the valid until date from 2022-07-14 to a date a few months after the 4.5.0 release. 3. Issue a point release (4.4.1) now that corrects the date to the desired 2022-10-21.
_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre
I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory the university stands and the Songhees, Esquimalt and WSÁNEĆ peoples whose historical relationships with the land continue to this day. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
MH> I would say #1. The worst that can happen is that one or two users will have to make a minor change in July, … Actually, users would not see the change until the next release, which I suspect would be in September before the meeting or shortly after the meeting. (Same logic applies, though.) RV> I lean towards 2 because it's slightly more transparent, but also susceptible to this same oversight after the next release... Except that we can make the change now, and users won’t see it until next release. ________________________________
1. Leave things as is, and just act on the deprecation on 2022-07-14. Yes, that makes the deprecation period pretty short, but who uses `<altIdent>` anyway? 2. Do nothing in July. For the _next_ release (call it 4.5.0, as that is likely what it will be) reset the valid until date from 2022-07-14 to a date a few months after the 4.5.0 release. 3. Issue a point release (4.4.1) now that corrects the date to the desired 2022-10-21.
participants (3)
-
Bauman, Syd -
Martin Holmes -
Raffaele Viglianti