Comment (by Roland Haas):

Hello Sam, what official docs we have on this is here:

https://docs.einsteintoolkit.org/et-docs/Policies_to_retire_functionality

So more or less what you describe.

Expect this to still catch people by surprise though. There is an (inofficial since I don't think we ever really discussed keeping it) list of deprecated and retired functionality that I try to keep here: https://docs.einsteintoolkit.org/et-docs/Deprecated_features (but the last entry is from 2020 so it is almost certainly not up to date).

No warning in the thorn to be deprecated is needed. Other codes do that, increasing levels of annoyance as the deprecation date, which is a fixed date recorded in the code, comes closer, up to and including refusing to run if the compiled functionality is too old. In the ET the warning comes in the form of a list of deprecated features in the release announcements and discussion in the ET calls.

Previous advise wrt to breaking changes is eg here:

Note that you cannot deprecate (change) default parameter values, since that would lead to silent changes in behaviour. This is not foolproof of course, just look at the trouble we have with GRHydro::sources_spatial_order and ADMMacros::spatial_order. Or at least it must have been a very very long time that anyone has ever relied on that default.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2742/change-seed_magnetic_fields-scheduling-so