PR here: https://github.com/apache/airflow/pull/15612
On Mon, Apr 26, 2021 at 4:38 PM Jarek Potiuk <[email protected]> wrote: > > Cool. So if no-one else objects till the end of week I will update the > description to include K8S and make it clear that such Python/K8S 'dropping' > will happen with minor version bump of Airflow.. > > J. > > On Mon, Apr 26, 2021 at 3:36 PM Kaxil Naik <[email protected]> wrote: >> >> Hi all, >> >> Dropping support for a Python version in my opinion is not a breaking change >> mainly because it does not affect current users. >> >> We will simply change python_requires field in setup.cfg: >> https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires. >> i.e. if we change it to python_requires='>=3.7', >> running pip install apache-airflow with Python 3.6 will install the last >> Airflow version that supports 3.6. While it will install the latest version >> for 3.7 and above. >> >> We already have it set to 3.6 and above currently. >> >> So in my opinion, dropping support for Python Version in a minor Airflow >> version is not a breaking change. >> >> Regards, >> Kaxil >> >> On Sun, Apr 25, 2021 at 6:17 PM Jarek Potiuk <[email protected]> wrote: >>> >>> Sure! No hurry with that - I'd love to hear community voices here too ! >>> >>> On Sun, Apr 25, 2021 at 6:53 PM Ash Berlin-Taylor <[email protected]> wrote: >>>> >>>> Major I'm fine with - but I think Kaxil may have a case to make that >>>> dropping support in a minor ver I think, so let's wait for his input. >>>> >>>> -a >>>> >>>> On 25 April 2021 16:29:29 BST, Jarek Potiuk <[email protected]> wrote: >>>>> >>>>> Any more comments? Are you Ash, and others concerned about dropping >>>>> Python version/ K8S versio without increasing the major version of >>>>> Airflow? >>>>> >>>>> On Mon, Apr 19, 2021 at 3:01 PM Jarek Potiuk <[email protected]> wrote: >>>>>> >>>>>> This is a very valid point. >>>>>> >>>>>> I think it would not mean breaking change. We already have a "rule" that >>>>>> changing/upgrading dependencies is not a breaking change on it's own. We >>>>>> might choose a different route for Python and K8S being rather "big" >>>>>> dependencies and only drop them with the major version upgrade of >>>>>> Airflow, but I honestly think we should treat it the same way. >>>>>> >>>>>> Both K8S and Python have shifted their release schedule to much faster >>>>>> gears than they used to, and they make all the effort to make them >>>>>> backwards compatible with Semver - still maintaining a reasonably long >>>>>> support schedule. >>>>>> >>>>>> I think if we drop support for all Python 3.* series or K8S 1.* series - >>>>>> yes that would be a backwards-incompatible change. But since the users >>>>>> can very easily now migrate to python 3.n with predictable 3.5 years of >>>>>> support, I think we should simply follow the suite. >>>>>> >>>>>> For example if we decide to support python 3.6 beyond Dec 2021 it means >>>>>> that there will be no critical security fixes released any more then - >>>>>> and it means that we would have to somehow monitor and mitigate them. I >>>>>> think. >>>>>> >>>>>> I think following the schedule of Python/K8S would help the community as >>>>>> a whole. >>>>>> >>>>>> WDYT ? Others? >>>>>> >>>>>> J. >>>>>> >>>>>> >>>>>> On Wed, Apr 14, 2021 at 2:47 PM Ash Berlin-Taylor <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> I guess it wasn't quite clear what "finish" means, particularly how it >>>>>>> interacts with SemVer and Airflow releases. >>>>>>> >>>>>>> Lets take Python 3.6 as a concrete example -- it is end of life at the >>>>>>> end of this year, 23rd Dec, 202 1 <https://endoflife.date/python> >>>>>>> >>>>>>> Does dropping support for Python 3.6, even if it is not supported count >>>>>>> as a breaking change to Airflow, needing a 3.0? >>>>>>> >>>>>>> -ash >>>>>>> >>>>>>> On Tue, 13 Apr, 2021 at 19:44, Jarek Potiuk <[email protected]> wrote: >>>>>>> >>>>>>> On Tue, Apr 13, 2021 at 2:35 PM Ash Berlin-Taylor <[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> This sounds good to me. >>>>>>>> >>>>>>>> >>>>>>>> The next question this leads me to is: when do we _drop_ support for a >>>>>>>> version of Python or Kubernetes? >>>>>>> >>>>>>> >>>>>>> I believe that's the first point in the proposal ("finish" = "drop"). >>>>>>> If that's not clear, I will change it to drop >>>>>>> Or maybe you mean some other form of "dropping support? >>>>>>> >>>>>>>> 1. We finish support for Python and K8S versions when they reach EOL >>>>>>>> (For Python >>>>>>>> 3.6 it means that we will remove it from being supported on >>>>>>>> 23.12.2021, for K8S >>>>>>>> the 1.19 version supports end in September 2021). >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> +48 660 796 129 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> +48 660 796 129 >>>>> >>>>> >>>>> >>>>> -- >>>>> +48 660 796 129 >>> >>> >>> >>> -- >>> +48 660 796 129 > > > > -- > +48 660 796 129 -- +48 660 796 129
