jscheffl commented on PR #41067: URL: https://github.com/apache/airflow/pull/41067#issuecomment-2294028892
> > Yeah. This is a concern. Should we have a branch called v2-dev where all airflow 2 PRs will go into, then the release manager would cherry-pick to v2-10-test when releasing? I think that having v2-11-test might make us miss PRs or having multiple places to PR to > > Shall we spin it off to a devlist discussion? Devlist discussion might be fair. Options that I see contributing above: 1. adding to main to then rip it out just to bring it to 2.x branch... beneficial would be at least having less differences between v2 and v3 for a moment... but benefit is small 2. adding to 2.10-test would be is you account it precise not a bugfix. But not merging it woul dmean that in 2.10 line the chance is high that the existing internal API is degrading very fast - that is why we had the tests added. Whereas the feature flag removal is just a feature flag removal. The PR is not adding functionality per-se but just enabling it. My main concern and pain is the high probability that the internal API degrades very fast in 2.x line. How about... we split the PR into: * Feature flag --> Airflow 2.11 to be cherry-picked - this will probably not have risk to degrade * Internal API Tests --> Merge to v2-10-test to ensure API works - is just adding tests, not "features" -- 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]
