jason810496 commented on issue #66454: URL: https://github.com/apache/airflow/issues/66454#issuecomment-4516643716
From my perspective, no matter what's the concrete idea looks like. The "version" should be decided by "server-side" (by Dag Processor, and by comparing the hash of `airflow-metadata` more specifically) instead of deciding on user side. So I think we can get rid of `Airflow-Bundle-Version`. Then the question will be how does Dag Versioning and Bundle Versioing works in Multi-Lang era. > How do we handle dag versioning with task-only (no dependency) JARs? If I understand correct, we mean "Multi-Lang Task" or "Python Stub Dag" here, right? ( We should align the term before the user-facing docs settle anyway ) We haven't support task versioning for stub operator. I don't have concrete idea for it now. It's likely a big design to discuss (e.g . introducing callback for dag-processing? When the Dag-processor realized this is a stub operator, it will launch coordinator to retrieve the multi-lang specific `airflow-metadata` and merge into the dag processing result. ) > How does versioning work with Java-only dags (where a binary is deployed)? This one should be easier. However, I feel we should change the coordinator configuration to respect the bundle to make it more feasible. > We should add Airflow-Supervisor-Schema-Version. That's true, I update the issue description to include it as well. If we include `Airflow-Supervisor-Schema-Version` in the metadata, then the `Airflow-SDK-Verion` is not necessary. -- 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]
