Lee-W commented on issue #54714: URL: https://github.com/apache/airflow/issues/54714#issuecomment-3685447224
> Thanks! > > I noticed the list with rule annotation ([#54714 (comment)](https://github.com/apache/airflow/issues/54714#issuecomment-3220353438)). [@Lee-W](https://github.com/Lee-W) , should we create the new code to cover all the changes mentioned in this task? I also noticed the following patterns: > > 1. move from airflow core into task sdk > > 2. move from airflow core into standard provider > > 3. one xcom def is moved to models > > Also, AIR311 and AIR312 are the ones that suggest users update, but won't break. Will the user still be able to use things like airflow.sensors.date_time.DateTimeSensor? If so, I think we'll need to create a new error code (e.g., AIR313 required to update after Airflow 3.1) > > Let me know if I understand it correctly. If user cannot use the old import, it's probably something like AIR301; we can introduce the new code (probably AIR321) to suggest a fix that points to the new import. For those moved into standard provider, we can use **AIR302**. The main reason we want to make it a separate code is that it's for airflow >= 3.1, not 3.0. Since Ruff cannot detect the airflow version. It would be better if we separate the code by minor version. And the AIR302 part, yes, that would be a better solution. Thanks! -- 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]
