Thanks Sumit for kicking off this discussion! I am in favor of approach #1 as well. Airflow software version can change due to none API related changes, but the client should only care about the public API contract. I believe this is also the same approach that the k8s python client took as well? For example, the k8s python client version 12.0.1 targets k8s api version 1.16.15.
I am also with you that clients for different languages should have their own release cycles. Other than testing burdens, every client could introduce their own bug fixes and breaking changes without having to trigger releases for all other clients. It would be a waste of work for us to bump the python client version just for a bug fix in the go client. Thanks, QP On Tue, Mar 30, 2021 at 1:56 AM Sumit Maheshwari <msu...@apache.org> wrote: > > Hello Airflow dev community > > I'm writing this mail in regards to seek feedback on the first release of > Apache Airflow's Python client. This is an icebreaker email only and we will > follow the Apache process of releasing the version later on. As of now, I've > raised a small PR to add the missing files in the repo, which are required to > do the release of the client lib. > > The main question I've in mind about the versioning. I see that there are > mainly two theories related to maintain the release versions of clients: > > The first is about following the semantic release of the clients on its own. > The release version of the client doesn't include the version of the software > itself. Something like we are doing with Airflow's provider packages. > However, in each release, we mention the release version of the main software > (Airflow in this case). This is the simple most way of maintaining releases > and followed majorly. > The second way is to include the software's version as well in its client's > versioning, something like it's been done in the K8s Python client. In this > approach, the client version provides more implicit knowledge about the > compatible software, however it creates an extra burden of releasing the > client with every minor release of the software, otherwise the versioning > would fall apart. Also, there is a good chance that most of these minor or > even a major release has no changes in the APIs, but the client would be > needed to re-released nevertheless, just to keep the versioning in check. > > Personally, I'm in favour of the 1st way, as it's simple to manage and > doesn't tightly couple client with its software. > > Another unrelated question I have is about the release of different client > libraries. As of now, Airflow has Python and Go clients, so should we try to > release them together or they should follow their own paths? In general, I'm > against batching them together, cause the person who is releasing them may > not be able to test all the different clients in the future. > > Let me know your thoughts on these 2 points. > > Thanks, > Sumit Maheshwari > PMC Apache Airflow
