Ok, seems like we are agreeing, I will follow up with a lazy consensus. Le jeu. 2 nov. 2023 à 14:43, Jarek Potiuk <ja...@potiuk.com> a écrit :
> Yeah. I thought a bit more about it and yeah, with next gen and the > versioning still aligned with airflow l we are likely to fall in the same > trap. And will have to come up with next-next-gen client :) . Even if for > example we decisr that we want to change some parameters of generator that > might produce a breaking change. > > > So yeah - I agree having versions completely disconnected from Airflow and > 'live their own life' is better. > > +1 to Pierre's idea > > czw., 2 lis 2023, 10:47 użytkownik Sumit Maheshwari < > sumeet.ma...@gmail.com> > napisał: > > > The ask by Pierre is very valid and makes a lot of sense. When we defined > > this versioning system, we took a lot of inspiration from Python clients > of > > other famous OSS software like Kubernetes & probably did not think of the > > versioning changes in the generator itself. > > > > I looked at the k8s python-client versioning > > <https://github.com/kubernetes-client/python#compatibility> and it seems > > they have also not considered it either. In fact, their versioning policy > > looks more brittle, and not sure how they gonna handle it when Kubernetes > > 2.x gets released. > > > > Anyway, I think it's time we've to break client versioning from Airflow > > versioning and maintain a compatibility metric (like k8s client does). > > > > Thanks, > > Sumit > > > > > > On Thu, Nov 2, 2023 at 2:24 PM Scheffler Jens (XC-DX/PJ-PACE-E03) > > <jens.scheff...@de.bosch.com.invalid> wrote: > > > > > Hi, > > > > > > I thought about the alternate proposal but as the old branch of openapi > > is > > > not really maintained if security problems pile-up it will in any way > not > > > be a path forward. If it would be long maintained I would have agreed. > > > (Whereas „nextgen“ is to be prevented because how to name the successor > > in > > > 2 years when nextgen to be deprecated 😀) > > > > > > Having two packages might also confuse users which to useand as of the > > > name if users make a lookup they might jump on the legacy one by > accident > > > (because name is intuitive) > > > > > > Therefor I‘d rather propose to go for a breaking.change and accept that > > > the client‘s version number is not in sync with Airflow anymore. > > > > > > Also this gives the opportunity to maintain a branch of the old if > needed > > > and still keep the same name. > > > > > > Jens > > > > > > Sent from Outlook for iOS<https://aka.ms/o0ukef> > > > ________________________________ > > > From: Jarek Potiuk <ja...@potiuk.com> > > > Sent: Wednesday, November 1, 2023 2:57:01 PM > > > To: dev@airflow.apache.org <dev@airflow.apache.org> > > > Subject: Re: [DISCUSS] API Clients Major version > > > > > > Alternative proposal. > > > > > > Why don't we release a new package 'python-client-nextgen' & with new > > build > > > process/generator and release process following the same versioning as > > > previously.. > > > > > > > > > The old python client will continue to work for current APIa but it > will > > > stop receiving new features so if someone would like to use the new > > > features, will have to switch to next gen (with consequences of > breaking > > > changes). > > > > > > I think it would be far more explicit and easier to communicate. And > many > > > other packages I know followed such approach. > > > > > > J. > > > > > > śr., 1 lis 2023, 13:49 użytkownik Pierre Jeambrun < > pierrejb...@gmail.com > > > > > > napisał: > > > > > > > Hello, > > > > > > > > This thread was originated from: > > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fairflow%2Fpull%2F34805&data=05%7C01%7CJens.Scheffler%40de.bosch.com%7Cce4743dcf53f40fdb59308dbdae281f7%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638344438594751145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TaIES%2FX1fHk5UqPfYakPeSTPukckMNGIq8ExjWcFcOg%3D&reserved=0 > > > <https://github.com/apache/airflow/pull/34805> that tries to upgrade > the > > > > generator version to 7.0.1. > > > > > > > > *Motivations/Context:* > > > > New versions of the openapi generator hold breaking changes in > regards > > to > > > > the clients code generated. For this reason, up to now we chose not > to > > > > upgrade the generator version. This causes several issues that are > > > stacking > > > > up, for instance some modern openapi keywords are poorly supported by > > the > > > > generator, go client is stuck on an old version of Go (insecure) we > are > > > > currently unable to release a new version for it, cf this PR > > > > < > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fairflow-client-go%2Fpull%2F43&data=05%7C01%7CJens.Scheffler%40de.bosch.com%7Cce4743dcf53f40fdb59308dbdae281f7%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638344438594751145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yFGNttuue3LXfXqPUHmXBMceYVSrz8Ir2lIePY%2FSnm0%3D&reserved=0 > > > <https://github.com/apache/airflow-client-go/pull/43>> and we are > > missing > > > a > > > > bunch of new features/security patches from the generator. Also as > > Jarek > > > > mentioned in this comment > > > > < > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fairflow%2Fpull%2F34805%23discussion_r1367956354&data=05%7C01%7CJens.Scheffler%40de.bosch.com%7Cce4743dcf53f40fdb59308dbdae281f7%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638344438594751145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yZDMG%2Fl%2F3vyro1Lkxu0E1pUno0P5M9tWnF0fcZMTjMo%3D&reserved=0 > > > <https://github.com/apache/airflow/pull/34805#discussion_r1367956354>> > > it > > > > might also be a good opportunity to update the build and release > > process > > > to > > > > improve security for our client packages. > > > > > > > > The current policy does not state how major versions should be > handled > > > for > > > > clients, and silently suggests that we never release a client major > > > > version, unless airflow 3 comes out. > > > > > > > > > > > > *Proposal:*What I want to propose is to update the API clients > release > > > > policy to allow breaking major versions for clients if needed, and > > > decouple > > > > even more core/client versioning. Client minor and major versions > would > > > not > > > > be in sync with core versions anymore, but I don't think it has to > be. > > > (it > > > > was already the case for patch version and it was never an issue) > > > > > > > > If this proposal were to be accepted, we would release a new python > and > > > go > > > > client major version (3.0.0) to fix the issues stated above and take > > this > > > > breaking change opportunity to push build and release process updates > > as > > > > needed. > > > > > > > > *Note:* > > > > Current clients Versioning policy: > > > > > > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fairflow%2Fblob%2Fmain%2Fdev%2FREADME_RELEASE_AIRFLOW.md%23api-clients&data=05%7C01%7CJens.Scheffler%40de.bosch.com%7Cce4743dcf53f40fdb59308dbdae281f7%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638344438594751145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uY5Ghsj1Ux2HPY6C0E%2BczPwp6N3%2F9c7CnrtaWvuPyTo%3D&reserved=0 > > > < > > > > > > https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md#api-clients > > > > > > > > > > > > > >
