Thanks QP for your feedback. I think the latest release of K8s client (v17.x.y) is moving in another direction.
On Wed, Mar 31, 2021 at 12:13 AM QP Hou <q...@scribd.com.invalid> wrote: > 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 >
