Update API version #27642
Update API version #27642
Conversation
pierrejeambrun
requested review from
mik-laj and
ephraimbuddy
as code owners
There was a problem hiding this comment.
I only see 2.3.0 at https://github.com/apache/airflow-client-python.
Did I miss anything here?
|
I thought the client was auto generated. Not sure what is the realease process for it ? |
Both python client and go client have seperated release process. |
|
Why we do not make release of the Python Client, part our regular release process @jedcunningham @ephraimbuddy? I think it is either no-op (when there is no change) , or it should be released at the same time as airflow. We should be able to release them at the same time when needed. WDYT? |
|
What do you think, should I amend this PR to only change the API version so we can merge it. Then open an issue for the python/go client version ? |
|
I made a PR a couple weeks ago to try to update the python client to 2.4.2 (apache/airflow-client-python#51). Waiting for merge, etc. Completely agree that the clients should be part of the regular release process. |
pierrejeambrun
force-pushed
the
update-api-and-client-version
branch
from
022f493
to
5d0f69d
Compare
pierrejeambrun
changed the title
|
I have updated the PR to only work on the API version. So we can decide and handle the api clients separately, go should also be taken into consideration, there is work on different repo to make etc... @csm10495 your comment makes me wonder if they should be released for all versions including patches. I mean, does it makes sense to patch the api spec ? 🤔 for me we either add, so it's a new feature and a minor version, or update/delete and its a breaking change. |
|
I figure it makes easy enough sense to match client version with airflow version, regardless of if there are API changes or not. That makes it simple for users to know which version of the client they should be using to ensure compatibility. Optimally: every new tag/release gets a corresponding client tag/release. |
|
I agree that this is much more practical, but having a new version with literally no diff compare to the prior and an empty changelog can be confusing. No strong opinion here I see benefits to both of them, just asking. |
|
I think having the changelog just be: "Updating version to match airflow... no api changes" would probably make enough sense ;P |
|
Yes this can be a solution 👍 I feel like having a dedicated place to brainstorm about this can be beneficial. Following @eladkal advice, started a discussion on the dev mailing list as this is more appropriate: |
|
For API clients - we actually have agreed to the versioning where MINOR.MAJOR are the same where PATCHLEVEL are separated. For example API client Python version 2.4.1 and Go client 2.4.3 might both be "latest" versions of clients - covering all fixes (1 and 3 rounds of them) since 2.4.0 has been released. By definition all 2.4 versions of Airflow only contain bug-fixes, not features/breaking changes. See: https://github.com/apache/airflow#semantic-versioning
Now - for API version itself, I feel we should do similar approach. - API 2.4 and any time we release any bugfix to API, we bump patchlevel |
|
To be clear: Does this mean that no new API features/endpoints/params until the next minor airflow release? (and i guess then no client support until after that next minor release?)... i mean that makes sense per semver. How does it work for the time period between initial push to airflow and the new minor rev of airflow being released? |
It means that when we release 2.4.0 Airlfow -> we should also release 2.4.0 of API. Then, when we release 2.4.1 Airflow - we might NOT release 2.4.1, depending if there are changes in the API. Theorethically there shouldn't be any "substantial" changes - but there might be some documentation changes, or fixing bugs we have not noticed that will impact API specification.
I am not sure if I understand, but API 2.4.0 should contain all the 2.4 API's and they should not change in any of the 2.4.* versions. If there are any missing things in API 2.4.0 that were there in Airflow 2.4.0, they are really bugs that should be fixed in 2.4.* of the APIs. and there should never be any new features in API 2.4. |
|
We can even release API 2.4.1 if Airlfow is still at 2.4.0 if we find a mistake in the API. |
pierrejeambrun
force-pushed
the
update-api-and-client-version
branch
from
5d0f69d
to
28769da
Compare
|
@potiuk For this change to take effect on the website documentation: Are there some additional steps needed ? For instance on the airflow-site repo, or will this be done for the next release ? |
|
Yes. We would need to generate documentation and release it. This is part of the Release process for Airflow: https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md We have no separate "doc only" release process for Airflow (we have it for doc-only providers). If we would like to change it in "airflow-site" it would have to be either: a) wait for and make sure it is released as part of the next Airflow release (that's one more reason why it should be a part of the release process - so that we do not forget to upgrade and relase the Python and Go API clients as well when we are releasing 2.5.0) b) we would have to introduce new variant of process of releasing doc-only update for airflow - this could be done by simply cherry-picking the doc changes to latest vX-Y--test and releasing documentation from that branch @jedcunningham @ephraimbuddy -> I think this is more relevant to your side of it so I think you need to have a say here |
|
I think we should just wait for 2.5 at this point, it's right around the corner. |
ephraimbuddy
added
the
type:misc/internal
|
Yep. |
We might have forgotten to upgrade the API and Python client version when releasing 2.4.
The stable release of the API is currently 2.3, we also have mentions of 'new in 2.4.0' in the current version.