We need to be also mindful about the fact that not everyone is able to migrate to the new Airflow version as soon as it's being released. One of the concepts of providers is that it's not tightly bound to Airflow core - If we can give users more time before setting a minimum version of airflow 2.3 that would be ideal. It's frustrating when a small bug fix that you really need is beyond your reach due to some other issue that forced bumping version. It may be more hussle for us but if we can release provider bug fixes/features first and a few days later release the breaking changes in a separate release it may be valuable for some users.
On Thu, Dec 30, 2021 at 8:11 PM Kaxil Naik <[email protected]> wrote: > 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. >> >
