Also the discussion was continued there https://lists.apache.org/thread/hjmrv1wc2rxhkvozpvccs4mhgwg5sw2f (for posterity)
On Mon, Jun 17, 2024 at 11:06 AM Jarek Potiuk <ja...@potiuk.com> wrote: > Hello everyone, > > Following the discussion > https://lists.apache.org/thread/r302p5b03dpyncswn11nkjn98cpb6r5z I would > like to call for a lazy consensus on introdiucing "common.compat" provider. > > Summarizing what has been discussed there (and some of my further > thoughts): > > * common.compat provider will contain compatibility code for earlier > versions of Airflow, that providers might use in case they need to handle > some back-compatibility code (example where it might be needed is here > https://github.com/apache/airflow/pull/39530) > > * as a rule, we should only keep compatibility code there (including > indication of version of Airflow where compatibility code is not needed any > more). New versions of providers should switch to the "airflow" code > gradually as soon as "min airflow version" is bumped to the version where > compatibility code is not needed. > > * the "common.compat" provider should be strictly backwards-compatible. We > will release version 1.0 and for a foreseeable future we will have to keep > it compatible in the future, which means that we will get some old "compat" > code lying around for quite some time. We might change it if we add some > retention policies for older versions of providers (We do not have them > now). This code should generally be not touched, and does not have to have > test coverage other than test coverage from providers using it) - so cost > of maintenance of that code should be **low** to **none**. > > * this will also make it possible to get some compatibility code for > Airflow 2 / Airflow 3 likely. > > The lazy consensus will last for 72 HRS and it will be effective as of > Thursday 20th of June ~ noon CEST. > > J. > > > > >
