bugraoz93 commented on issue #65497: URL: https://github.com/apache/airflow/issues/65497#issuecomment-4282276211
> > Install note: Required httpx==0.28.1 pin — RC ships httpx==1.0.dev3 which removed HTTPStatusError, crashing on startup. > > That's interesting - it likely means we will have to upper bind it or pin it (BTW. You do not need to use pre-release flag - you can **just** install the version with `==0.1.4rc2` - then it will not use the pre-release httpx. Yes, indeed. Pinning or capping with highest version until we are compatible with newer versions sounds great! > > Add is_backfillable property to DAG API responses ([#64644](https://github.com/apache/airflow/pull/64644)): [@Dev-iL](https://github.com/Dev-iL) > > Is it not a problem that this change targets airflow-core 3.3.0? > > This is a good question - and one of the problems that we anticipated might happen [@bugraoz93](https://github.com/bugraoz93) ? It **was** supposed to be backwards compatible, so the question is whether it is and how. > > I thought about relesing from `v3-2-0-test` - but it has a bit different issue, there 3.2.0-test is just a "test" branch that shoudl be actually reviewed before merging with`v3-2-0-stable` so maybe we need some kind of `airfflow-ctl/v-1-4-test` and stable ? I'd love to hear your thougts on it [@bugraoz93](https://github.com/bugraoz93) :) ? That is a great question indeed :D This could be a breaking change for release from `main` with any `3.2.x` versions if we wait to release the API side. This can impact all the `airflowctl dags` commands, as it has been added to most core `DAGResponse` model. Not last but previous Sunday, I compared datamodels between `main` and `v3-2-test` datamodels, which were in sync https://github.com/apache/airflow/pull/65069 and thought it is safe to release. It seems that after check and before release, this has been merged and I have missed it :D To be honest, after hearing your thoughts on releasing from `v3-2-0-test`, I backported everything to be ready there :) So ideally, we are ready to release from `v3-2-test` and populate the release notes, etc. from main, but still have the problem of polluting the actual Airflow release commits and the flow, as you mentioned on the sync review part. I like the idea of having separate branches for test and stable. One friction we would add is syncing Airflow core changes into `airflow-ctl/v-1-4-test`, but that could rather be the safer option, as we can either fast-forward core changes directly from the `v3-2-test` branch or cherry-pick and can revert from there when needed. I am still even considering your last suggestion, merging releases with Airflow and TaskSDK, as we also join as RMs to core to reduce the total amount of effort to release packages. It can make this even safer and could be the safest among all, even though making releases highly coupled will also have its own cons and some effort by the side :) First approach, your current suggestions, we can make it rather easily to have a separate test branch (as we did for Helm as well). Branching from `v3-2-test` to `airflow-ctl/v-1-4-test` and creating a stable branch from it when we release the first version from the new test branch should do the trick. I still need to check shifting integration tests, as we won't run canary other than the `v3-2-test` branch, which could be the only friction in my mind for shifting the release approach -- 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]
