Previous phrasing was misleading - it implied a given module was explicitly on
the blacklist, even if it was due to a restrictive whitelist and the blacklist
was empty.
Arguably the blacklist/whitelist semantics are themselves misleading. A
redesign is tempting.
This shouldn't change the interpreter ultimately chosen by Ansible. It should
only improve the hit rate of performing interpreter discovery, particular in
cases where only pythonX.Y is present on the target.
Interpreter discovery may take longer or shorter, depending on the Ansible
version and the interpreters present on the target.
* :gh:issue:`1385`:mod:`ansible_mitogen`: Remove a use of
``ansible.module_utils.six``
* :gh:issue:`1354` docs: Document Ansible 13 (ansible-core 2.20) support
* :gh:issue:`1354`:mod:`mitogen`: Clarify error message when a module
request would be refused by allow or deny listing
v0.3.35 (2025-12-01)
--------------------
* :gh:issue:`1132`:mod:`ansible_mitogen` During intrepreter discovery use
Ansible ``INTERPRETER_PYTHON_FALLBACK`` config as list of candidates
v0.3.34 (2025-11-27)
--------------------
@ -430,7 +448,7 @@ v0.3.1 (unreleased)
* :gh:issue:`878` Kubectl connector fixed with Ansible 2.10 and above
v0.3.0 (2021-10-28)
v0.3.0 (2021-11-24)
-------------------
This release separates itself from the v0.2.X releases. Ansible's API changed too much to support backwards compatibility so from now on, v0.2.X releases will be for Ansible < 2.10 and v0.3.X will be for Ansible 2.10+.
@ -443,7 +461,7 @@ This release separates itself from the v0.2.X releases. Ansible's API changed to