potiuk commented on PR #35972: URL: https://github.com/apache/airflow/pull/35972#issuecomment-1862387487
> Since 2.8.0 does not contain logic to handle the new format, a provider cannot change its `provider.yml` until it drops support to the version. Well. Provider.yaml and Provider.info had been (since 2.0.1 where we defined the schema, 2.0.0 indeed had the problem you mentioned) built for extensibility - it means that you can add any exteelements to `provider.yaml` - they are verified at `main` via validating the schema and they are validated by earlier versions of Airflow via earlier provider schema, but this schema allows to add extra elements that get ignored. So it's perfectly fine to add new elements to provider.yaml (and they get exposed via `get_provider_info` ) as they will be simply ignored by earlier versions of Airflow. Similarly if a provider adds a new functionality that shoudl only be used in later version of Airflow (say exposing FS interface), we have the mechanism of throwing "AirlfowOptionalProviderFeatureException" during importing of relevant modules (for example when there is missing import or where we simply recognize that this module gets imported in the environment where it should not be - for example by checking airflow version). This is the way how you can add features from "future" versions of Airlfow even even your provider still supports 2.6+ I believe these two mechanisms solve whatever comatibility problems there might be and they do not "block" any changes in provider.yaml. Or are you talking about something else? Maybe there is a bug or a scenario that is not handled well? Coudl you please give an example of where are you blocked? -- 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: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
