I also agree with this idea. It is always a good idea to be up to date with the python dependencies as they have fixes for performance, scalability among other things.
As long as users have a mechanism to go back to the python version of their interest, I do not see any problem in proceeding with this kind of a change coming in. Thanks & Regards, Amogh Desai On Fri, 17 Nov 2023 at 11:40 AM, Wei Lee <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
