Thanks, Sumit, for bringing this up. - Regarding *versioning for Python client*: I favour the 1st way as well. The only minor comment I have is: instead of "*mention the release version of the main software*", possibly what users would expect is a "*range of compatible versions of main software*". If we follow semver for Airflow itself relatively strictly, this should not be hard.
- Regarding *the release of different client libraries*: I agree with you. They should be versioned & released separately. Regards, XD On Wed, Mar 31, 2021 at 9:21 AM Sumit Maheshwari <sumeet.ma...@gmail.com> wrote: > 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 >> >
