jscheffl commented on PR #68074: URL: https://github.com/apache/airflow/pull/68074#issuecomment-4694585870
> After a couple of days of thinking about it, I think we should do it differently. At first, I believe that we should have this feature to use the Airflow public interface (if I recall correctly, @jscheffl mentioned something about that here too). If we do not, it can work for 3.2.0 and not work for 3.2.1, as the non-public interface can change, and as a chart supports multiple different versions of Airflow, I think that we should be sure that it will work for all supported versions in the chart. Without that guarantee, this feature can be basically useless when it is needed during the upgrade. > > Regarding the `db_migrate.py` script, I think that most of the logic there should be part of the Airflow CLI. In the chart, we could just invoke `airflow db migrate --bidirectional ...` or sth like that, which would do everything, and we would be sure that it will work properly for all Airflow versions. While I think that it would be "cool" to use public interfaces I think ... the dilemma we are in is that this would get (earliest, we are cutting 3.3.0 in 2 days) into 3.4.0, which means you could only offer to downgrade to 3.3.0 and not earlier. But as we support all down to 3.0.0 we either only have this as a partial feature and leave many (installed base) use case outside. So for me would be OK like now and aimming to improve to a public interface for next released. Then depending on the version either the "new public" or "old method" is used. Once we drop support for the current versions we could clean-up. -- 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]
