Agreed, as long as users can still use different versions through tags, there are no drawbacks or incompatibilities with this great idea!
Best, Wei > On Nov 17, 2023, at 1:39 PM, Aritra Basu <aritrabasu1...@gmail.com> wrote: > > Agreed, moving to latest by default sounds like a fine idea. I don't see > any drawbacks to it and seems like a good enough time as any to make the > switch with 2.8.0. > > -- > Regards, > Aritra Basu > > On Fri, Nov 17, 2023, 12:33 AM Vincent Beck <vincb...@apache.org> wrote: > >> I agree, by default we should use the latest python version. Like any >> package manager, if the user does not explicitly specify a version, the >> latest should be used. If the user wants to use a lower version, he can >> always pin it. >> >> On 2023/11/16 12:06:17 Jarek Potiuk wrote: >>> Hello everyone, >>> >>> Since we are close to the Airflow 2.8.0 release, I would like to propose >> a >>> change in the approach for our "default" images. >>> >>> Currently there are few images that are considered as "default", for >>> example: >>> >>> apache/airflow:latest >>> apache/airflow:2.7.4 >>> >>> Currently (according to our process [1] and user documentation [2]) those >>> point to the "oldest" python version we support (currently they point to >>> Python 3.8). >>> >>> There is no particular reason why it is like that, and with Airflow 2.8.0 >>> we have an opportunity to change it and point the default images to >> "latest >>> supported" (and keep this version as default for the whole MINOR line of >>> releases. >>> >>> In the case of Airflow 2.8.* - that would be "Python 3.11" being default >>> for the whole 2.8.* line unless we manage to get Python 3.12 support in >> our >>> CI before we release Airflow 2.8.0, then it would be Python 3.12 >>> >>> We do not have any SemVer promises about that. Users can still choose to >>> use the "2.8.0-python3.8" tag if they want. >>> >>> Generally going to 2.8 should always be a deliberate action, so we have >>> chance to explain in the release notes that if they want to stick to the >>> 2.8 release. So they are not "losing" anything, they can have 100% >>> compatibility by just choosing a different image in their deployment. >> This >>> **might** cause a little hassle when they migrate if they find some >>> incompatibilities, but generally speaking it's a very straightforward and >>> simple change - just adding "-python3.8" to your TAG - whatever >> deployment >>> option you have. And our users will have to go through it anyway every >> time >>> we drop the old Python version (and this change might be even more costly >>> as they have no choice then) - so it changes very little, just shifts the >>> time where they will have to do it. >>> >>> There are benefits of doing it - for both our users and well, environment >>> as well (and I really mean a positive impact on the "world environment" >> to >>> be honest. Maybe a little impact - but with Airflow's popularity, it >> might >>> make a (small) difference. Python 3.11 is generally 30% faster than >>> previous versions and using it by default means that 30% less CPU is >> being >>> wasted. Also it will mean actual money savings for our users. Also Python >>> 3.12 comes with even more performance improvements and keeping up with >>> those being the "default" is a pretty good idea. >>> >>> I cannot think of any other drawbacks of this change. >>> >>> WDYT? >>> >>> [1] Documented versioning approach: >>> >> https://github.com/apache/airflow#base-os-support-for-reference-airflow-images >>> [2] User documentation >>> https://airflow.apache.org/docs/docker-stack/index.html >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >> For additional commands, e-mail: dev-h...@airflow.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
