potiuk commented on issue #39100:
URL: https://github.com/apache/airflow/issues/39100#issuecomment-2064053468

   Yes I think it might make sense to put some limits, but it's hard to say 
what those limits should be.
   
   Generally speaking, the point of having old providers (even very old) and 
new Airflow is the whole point of separating providers and Airflow - simply, if 
provider has breaking changes, users can still upgrade Airflow but keep 
**some** providers not updated to latest versions. 
   
   The question is: "DEFINE REASONABLE". We already have  some rules that we 
follow on providers supporting minimum Airflow versions - and those rules are 
well defined. 
https://github.com/apache/airflow/blob/main/PROVIDERS.rst#upgrading-minimum-supported-version-of-airflow
 
   
   If someone will come up with a proposal for what would be "REASONABLE", I 
think it makes sense - the extra `limits` are not hard - they are soft, so it 
does not even "block" the users if they want to use older versions. 
   
   If so - maybe a good idea will be to raise the proposal as discusison in our 
devlist - this is where we discuss such ideas - for example the 12 months 
policy for providers have been discussed in: 
   
   * https://lists.apache.org/thread/csczm7xmnntdz9wtjbod8pqgt13zoggo
   
   and lazy consensus proposed and achieved here:
   
   * https://lists.apache.org/thread/43v1dnww37t0o924mzo365ot2p58k864
   
   Similarly - discussion should be started, with reasoning and proposal, and 
then after achieving a consensus, we should implement it. I am all for it and I 
am also super-happy to guide someone doing it. IT's been a long time I was 
**doing** all these things myself, but this time I started to think about 
others stepping in and driving this - I am happy to support and guide 
implementation of it so if you feel like it @notatallshaw -> I would be 
super-happy to take the back seat on that one.
   


-- 
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]

Reply via email to