Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:
Description
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:
- Deprecation of the Filter class and dependent APIs in Science Pipelines release 22 (the earliest possible, unless we create a 21.1 release)
- Removal of Filter in release 23 (dev guide requires release 24)
- Deprecation of transitional APIs called, e.g., getFilterLabel instead of getFilter in release 23 (blocked on removal of original getFilter, etc.)
- 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.
Attachments
Issue Links
Activity
On further thought, no, I don't think I want to go that far. While it's important to get people using FilterLabel and to remove Filter as quickly as possible, it's also important to make sure we tie up any loose ends (especially handling old files, which is proving tricky). I think removal of Filter in release 23 strikes a good balance.
For the record, we had three major releases last year, and two major and one minor release the year before. I'm assuming that means release 23 (when I propose removing Filter) will be around late summer, and release 24 (the removal date if no special action is taken) a year from now.
Krzysztof Findeisen
added a comment - - edited On further thought, no, I don't think I want to go that far. While it's important to get people using FilterLabel and to remove Filter as quickly as possible, it's also important to make sure we tie up any loose ends (especially handling old files, which is proving tricky). I think removal of Filter in release 23 strikes a good balance.
For the record, we had three major releases last year, and two major and one minor release the year before. I'm assuming that means release 23 (when I propose removing Filter ) will be around late summer, and release 24 (the removal date if no special action is taken) a year from now. Has the CCB reached its decision yet?
Krzysztof Findeisen
added a comment - Has the CCB reached its decision yet? Yes. The CCB approved your plan yesterday (sorry the delay).
With the merge of DM-27170, this plan is now implemented in the various deprecation warnings that were added on that ticket.
What I think we're trying to say is, would you like to define a faster process? Not "can it be instantaneous". We are open to an approach where we do not have to mediate the entire migration through multiple formal releases for example. Maybe pre-announcing special weeklies as being the transition boundaries instead. We are asking if you prefer a faster timeline.