Re: Releasing Apache Airflow's Python Client

I think it's OK to conclude the release strategy for clients: So the first two digits of the client's release number will be borrowed from the first two digits of Airflow's release. The last and third digit would be independent of the Airflow release and will denote any patches done on the client

Re: Releasing Apache Airflow's Python Client

I think I'm fine with the approach you suggested Jarek. This approach mitigates the need to release clients with each patch release of Airflow, and that does make sense. I hope that others are fine as well with the approach, where we've to release clients with every major or minor release of Airfl

Re: Releasing Apache Airflow's Python Client

Hmm. I think it's a great direction, but 4 digits is a bit too much :) keeping three-digit SemVer is good for clarity/tools. And itroducing 4th digit is not really needed i think. Your proposal Sumit made me think, and I asked myself a few questions: 1) will we ever release API client new featur

Re: Releasing Apache Airflow's Python Client

Thanks, everyone for the inputs. I think it's clear that we want to go with the hybrid way of versioning. Given that we can automate the client releases easily, how if we release a client automatically with each Airflow release, and go for a four numbered release, where the first three would be th

Re: Releasing Apache Airflow's Python Client

Sumit, Thank you for bringing up this discussion. Reading through the thread, I am definitely far more comfortable with the hybrid approach proposed by Kaxil, than the first approach, primarily because of the same concerns articulated by Jarek regarding end user experience. Prior to that, I was le

Re: Releasing Apache Airflow's Python Client

I also like the hybrid approach proposed by Kaxil. It is not as simplenfor dependency management as 1-1 version, but IMHO it is simple-enough. As long as we strictly follow SemVer, a number of questions i listed above from the user, are answered: 1) Will my client be compatible with the version o

Re: Releasing Apache Airflow's Python Client

+1 for Kaxil proposal I think, attempting to assign a specific client version to the library application makes no sense in creating an API that is based on a strict specification. One of the goals of this API was to make it easier to manage multiple instances, and it's not often that you have an

Re: Releasing Apache Airflow's Python Client

Thanks, Sumit, for bringing this up. re: *versioning for Python client*: I favour a bit of a hybrid of 1 and 2. Initially, I favored just (1) when we talked but after seeing how Elastic-Search does it I liked their versioning strategy. How their python-client is compatible with ES itself is docum

Re: Releasing Apache Airflow's Python Client

I think there are more questions we need to answer when it comes to different versions. If we are going to different versioning for agent and Airflow, we will have to accept the fact that over time people will have a "matrix of versions" - for both Airflow and the client. And this introduces "depen

Re: Releasing Apache Airflow's Python Client

Yep, if we can, I would prefer to explicitly mention something like 2.0.X :) On Wed, Mar 31, 2021 at 10:54 AM Sumit Maheshwari wrote: > 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 semant

Re: Releasing Apache Airflow's Python Client

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 t

Re: Releasing Apache Airflow's Python Client

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*".

Re: Releasing Apache Airflow's Python Client

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 wrote: > Thanks Sumit for kicking off this discussion! > > I am in favor of approach #1 as well. Airflow software version can > change due to no

Re: Releasing Apache Airflow's Python Client

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?

Releasing Apache Airflow's Python Client

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 no