Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-748

Accelerated deprecation of Filter

    XMLWordPrintable

Details

    • RFC
    • Status: Implemented
    • Resolution: Done
    • DM

    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:

      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.

      Attachments

        Issue Links

          Activity

            Escalating as it involves both an API deprecation and an exemption to the normal deprecation procedure.

            krzys Krzysztof Findeisen added a comment - Escalating as it involves both an API deprecation and an exemption to the normal deprecation procedure.
            Parejkoj John Parejko added a comment -

            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.

            Parejkoj John Parejko added a comment - 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.
            jbosch Jim Bosch added a comment -

            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.

            jbosch Jim Bosch added a comment - 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.
            jbosch Jim Bosch added a comment -

            krzys, 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?

            jbosch Jim Bosch added a comment - krzys , 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?

            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.

            krzys 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.
            tjenness Tim Jenness added a comment -

            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.

            tjenness Tim Jenness added a comment - 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.
            krzys 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.

            krzys 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?

            krzys Krzysztof Findeisen added a comment - Has the CCB reached its decision yet?
            tjenness Tim Jenness added a comment -

            Yes. The CCB approved your plan yesterday (sorry the delay).

            tjenness Tim Jenness added a comment - 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.

            Parejkoj John Parejko added a comment - With the merge of DM-27170 , this plan is now implemented in the various deprecation warnings that were added on that ticket.

            People

              krzys Krzysztof Findeisen
              krzys Krzysztof Findeisen
              Ian Sullivan, Jim Bosch, John Parejko, Kian-Tat Lim, Krzysztof Findeisen, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                Jenkins

                  No builds found.