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 <mholmes@uvic.ca> wrote:
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