potiuk edited a comment on pull request #20549: URL: https://github.com/apache/airflow/pull/20549#issuecomment-1002684393
> I'm not opposed to keeping ones that are intended to be cherry-picked back, but why wouldn't we want to remove all the others? And why _after_ 2.3.0, why would we need/want them shipped in that version? We could do it even now - but only if we accept the risk that things won't work for Python 3.6 when we cherry-pick something to 2.2.4 (or 2.2.5 if we have it). We do not yet know all the stuff we will be cherry-picking (and we can decide tomorrow or in a week that we cherry-pick something new). This is connected with the risk, that during cherry-picking some of those 'if PY36' will be removed and we will not realize that because the cherry-pick will cleanly apply and our tests might not catch it. As a result we might have failing 2.2.4 on Python 3.6 in some cases. Why waiting until 2.3.0 might help ? Because (at least so far) releasing 2.N.0 is the time we stop "mass-cherry-picking" to 2.N-1 branch. So far I think we have not done even once a release for previous minor release once we released 2.N.0. This also decreases the risk of such accidental Python 3.6 removal if we decide to release an urgent bugfix in 2.N-1. (because we will be very selective with cherry-picks). We do not yet know how soon we will release 2.3.0 - it depends on many factors, and we do not know if we will have 2.2.4 or maybe even 2.2.5 and how many cherry-picked commits we will have there - it really depends on whether we will find and fix more important bugs until 2.3.0 is released. So this is really a question of how confident we are that this will not be a problem. I think it's up to you to decide - you are the release manager :D. But you should take the risk into account - and decide consciously to accept the risk. And if you are fine with that I am also fine. I just put "request changes" so that this is not merged accidentally, the case is discussed and decision is made with the risks in mind :). -- 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]
