One other solution for just using "utils" from core is we can release "airflow.backports" or "airflow.futures" package same as Python Backports <https://pypi.org/project/backports/> and Python Future <https://pypi.org/project/future/> where we can handle the compat shim without restricting Airflow versions.
Regards, Kaxil On Thu, Dec 30, 2021 at 2:56 PM Jarek Potiuk <[email protected]> wrote: > > At this point, I think 2.3.0 will be around early Feb to get AIP-42 in. > We can reassess how the progress is moving ahead with the AIP mid-Jan and > based on that we can either release 2.3.0 end of Jan without AIP-42 changes > and mark it for 2.4.0. > > Yeah Agree here. I do not think we need to make a decision now - we > can do it later. But I'd love to hear various opinions - from our > users, various stakeholders (Amazon/Google/Astronomer who run it as a > service for one). > > Just to be clear - I am not fully convinced myself if this is the > right time to do it already (but there are some good indicators that > we should at least start discussing it). > > This is more opening the discussion and gathering feedback/feelings of > people. I think such decisions should be discussed (and their > consequences realized) well in-advance so that at the time of decision > we have all arguments and opinions and know the consequences. > > And it is not "strictly" necessary. It's just (like with all similar > cases) an increased burden for maintenance and extra/boilerplate code > that might be removed. In those cases there is rarely a "0/1" decision > that can be made "here we know for sure that we should increase > min-version" - it's more of the collective thinking: "Are the > burden/overhead heavy enough we don't want to carry it any more as a > community". > > J. >
