I'm more inclined towards decoupling core and client, and releasing a new major version. It would make sense to introduce breaking changes with the new major version.
I think I'm not too sure on the value add of having the old client and the new client. Interested in hearing others opinions on this. -- Regards, Aritra Basu On Wed, Nov 1, 2023, 7:27 PM Jarek Potiuk <ja...@potiuk.com> wrote: > 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://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://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://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://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md#api-clients > > >
