RFC-730 agreed to the deprecation of afw.image.Filter as part of the process of replacing it with FilterLabel. We later agreed on #dm-naming-things that the final APIs should say "Filter" (e.g., getFilter, which returns a FilterLabel), to prevent future users from having to deal the fact that we changed filter classes. Although this decision implies the deprecation of any methods with names like getFilterLabel, this deprecation was never formally approved.

I then published a Community post that gave the following sequence of events, not realizing it contradicted the developer guide:

1. Deprecation of the Filter class and dependent APIs in Science Pipelines release 22 (the earliest possible, unless we create a 21.1 release)
2. Removal of Filter in release 23 (dev guide requires release 24)
3. Deprecation of transitional APIs called, e.g., getFilterLabel instead of getFilter in release 23 (blocked on removal of original getFilter, etc.)
4. Removal of transitional APIs in release 24 (dev guide requires release 26)

This RFC formally proposes the elements of this transition that were not addressed by RFC-730, namely:

• the transitional status of components like getFilterLabel, and
• the deprecation of all components for only one major release rather than the two prescribed by the developer guide.

While I realize it will cause some trouble for users, an accelerated deprecation timeline will let us remove Filter and its global registry quickly, something I understand is blocking Gen 3 work on multi-instrument repositories.