Yeah totally agrees with you XD about the range vs the fixed version of the main software. And with Airflow 2 dot & beyond, we would be following the semantic versioning more judiciously, so with that can we assume that users would be cognizant of the related Airflow version implicitly, or do you think we should mention something like *2.0.X* in the changelog explicitly?
On Wed, Mar 31, 2021 at 1:38 PM Deng Xiaodong <xd.den...@gmail.com> wrote: > 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 >>> >>
