utkarsharma2 commented on PR #41610: URL: https://github.com/apache/airflow/pull/41610#issuecomment-2299021591
> > I'm wondering how we would actually handle the case where one of those backport commit do modify the openapi spec (for instance fix a parameter type) between the time when airflow core is released, and we have not yet released the related client version. > > I tihnk the issue can be solved by timing of releases. If we generate and client changelog / make decision whether we release API and decision on the version of the client at the sama time when we release Airflow, this would be a non-issue. In this case several days passed since and circumstances and environment changed (new dependencies released that required some actions, PRs were merged to v2-10-test) > > @ephraimbuddy @utkarsharma2 @jedcunningham -> WDYT. Yes, we can decide and move forward with the client release quickly. However, there's a caveat based on my limited experience with Airflow releases: they can become quite hectic. Handling two releases back-to-back could be taxing for the release manager. I would prefer if we could decouple the release processes. The way I see it, we need to update the changelog and make the necessary version changes in both the 2-10-stable and 2-10-test branches. This can be done by submitting separate PRs for each branch, allowing us to continue the release from the 2-10-stable without any unexpected changes and not being concerned about what's added in the 2-10-test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
