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

            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.