Minor 1.11.0 break 1.10.4 on `drop_constraint() takes 2 positional arguments but 3 were given`

[YonatanKiron]

Describe the bug

I'm using airflow, and it's depends on alembic<2.0,>=1.5.1 (Airflow 2.3.4)
Since yesterday, we are experiencing an issue that:

  File "/home/jenkins/agent/workspace/anager_airflow_run_tests_PR-1537/.tox/py/lib/python3.8/site-packages/airflow/migrations/versions/0093_2_2_0_taskinstance_keyed_to_dagrun.py", line 157, in upgrade
    batch_op.drop_constraint('task_reschedule_dag_task_date_fkey', 'foreignkey')
TypeError: drop_constraint() takes 2 positional arguments but 3 were given

It seems like, from some reason, that alembic 1.11.0 breaks 1.10.4

Expected behavior

• In case of breaking change, bump major not a minor 🤷🏼‍♂️
• Not breaking minor version
• Test to would have catch that scenario

To Reproduce
Please try to provide a Minimal, Complete, and Verifiable example, with the migration script and/or the SQLAlchemy tables or models involved.
See also Reporting Bugs on the website.
Install airflow 2.3.4
run airflow db init

# Insert code here

Error

  File "/home/jenkins/agent/workspace/anager_airflow_run_tests_PR-1537/.tox/py/lib/python3.8/site-packages/airflow/migrations/versions/0093_2_2_0_taskinstance_keyed_to_dagrun.py", line 157, in upgrade
    batch_op.drop_constraint('task_reschedule_dag_task_date_fkey', 'foreignkey')
TypeError: drop_constraint() takes 2 positional arguments but 3 were given

Versions.

• OS:
• Python: 3.8.11
• Alembic: 1.11.0
• SQLAlchemy: 0.41.1
• Database: postgresql/sqlite
• DBAPI:

Additional context

Currently, we strict our alembic version in out requirements.txt just want to raise this flag 🎏

Have a nice day!

[zzzeek]

We will check version for where autogenerate was doing this and add to our fixes, but just so you know alembic and sqlalchemy don't do pure semver and 1.11 is a "major release". we do plan to deprecate these calling styles in 1.12 or so

[zzzeek]

Alembic's autogenerate always generated this argument as a keyword argument, but it looks like we have one example in the docs that uses this positionally, so I will assume airflow devs worked from that example here.

Airflow will have to update this migration at some point though

[sqla-tester]

Mike Bayer has proposed a fix for this issue in the main branch:

restore drop_index.table_name, drop_constraint.type_ as positional https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/4618