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
Krzysztof Findeisen
created issue -
Krzysztof Findeisen
made changes -
Krzysztof Findeisen
made changes -
Krzysztof Findeisen
made changes -
| Status | Proposed [ 10805 ] | Flagged [ 10606 ] |
Krzysztof Findeisen
made changes -
| Description |
I then published a [Community post|https://community.lsst.org/t/4591] that gave the following sequence of events, not realizing it contradicted the [developer guide|https://developer.lsst.io/stack/deprecating-interfaces.html]: # 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 covers the aspects of this transition that were not addressed by * 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. |
I then published a [Community post|https://community.lsst.org/t/4591] that gave the following sequence of events, not realizing it contradicted the [developer guide|https://developer.lsst.io/stack/deprecating-interfaces.html]: # 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 * 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. |
Krzysztof Findeisen
made changes -
Krzysztof Findeisen
made changes -
| Planned End | 08/Jan/21 1:00 AM | 09/Jan/21 1:00 AM |
As one of the people involved in the discussion that resulted in this RFC and who is doing a chunk of the deprecation work, I think this is a very good idea.
While the Filter singleton isn't directly blocking Gen3 work, it does frequently lead to extra work and unexpected bugs.
I also think more generally that for a project like ours, where we are our own primary users (albeit not the only users), our deprecation policy is a good fit to our needs only if we can occasionally make well-reasoned exceptions like this to speed up transitions.
Krzysztof Findeisen, we discussed this at CCB today, and have a follow-up question: if the argument is that we should speed up the transition because time spent in the transition is more painful than just getting it over worth, would you want to speed it up even further than the proposal here?
| Remote Link | This issue links to "Page (Confluence)" [ 27143 ] |
Can you be more specific? I think we do need some deprecation period for Filter because it affects every user, and not all code conversions are trivial. So while I might support a greater speed-up, I wouldn't want an instantaneous transition.
Krzysztof Findeisen
added a comment - Can you be more specific? I think we do need some deprecation period for Filter because it affects every user, and not all code conversions are trivial. So while I might support a greater speed-up, I wouldn't want an instantaneous transition. 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.
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. | Remote Link | This issue links to "Page (Confluence)" [ 27221 ] |
Has the CCB reached its decision yet?
Krzysztof Findeisen
added a comment - Has the CCB reached its decision yet? | Status | Flagged [ 10606 ] | Board Recommended [ 11405 ] |
Yes. The CCB approved your plan yesterday (sorry the delay).
Krzysztof Findeisen
made changes -
| Status | Board Recommended [ 11405 ] | Adopted [ 10806 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 27253 ] |
| Resolution | Done [ 10000 ] | |
| Status | Adopted [ 10806 ] | Implemented [ 11105 ] |
With the merge of DM-27170, this plan is now implemented in the various deprecation warnings that were added on that ticket.
Escalating as it involves both an API deprecation and an exemption to the normal deprecation procedure.