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.