Repository navigation
Conversation
c1aa356 to
343b703
Compare
343b703 to
a225862
Compare
618e2ef to
103f825
Compare
1659d13 to
dade363
Compare
| ``allow_modifications=True`` is checked the same way. ``db_conn_id`` with | ||
| ``table_names``, ``schema_context`` or ``datasource_config`` give the model the | ||
| schema. | ||
| schema. ``datasource_config`` is experimental; see below. |
There was a problem hiding this comment.
1.0.0 shipped datasource_config and data_sources in these stable rows, and the top of this page says a stable feature keeps its public parameters until the next major release, so moving them to experimental in 1.x is what that policy rules out. The datafusion<52 pin was already there in 1.0.0. I asked for this before 1.0.0 went final, so that one's on me, but now I'd keep both stable, drop the two experimental-table rows and the operator notes, and mention the pin as a dependency caveat.
| --------- | ||
|
|
||
| .. note:: | ||
| ``airflow.providers.common.ai.toolsets.logging.LoggingToolset`` (public since 0.1.0) is |
There was a problem hiding this comment.
1.0.0 also shipped the package-level export from #74449 (the Features entry below), so from airflow.providers.common.ai.toolsets import LoggingToolset breaks too, and that's the import the 1.0.0 toolsets page showed. Could the note name both paths? On the rebase it needs to stay above main's new 1.1.0 section, since 1.1.0rc1 still ships the class.
| ``exclude-newer`` window, which for the OpenAI Agents SDK means the newest release that | ||
| accepts ``openai`` 2.x, not the versions in the table above. It therefore does not show | ||
| that those versions work in the environment a user gets. Canary runs, which include | ||
| scheduled, push and manual runs on the Apache Airflow repository and pull requests |
There was a problem hiding this comment.
Push runs don't get the framework pins: ci-amd.yml has no push trigger for main, and on a v*-test push run_agent_framework_tests returns False because providers release from main only. That leaves scheduled and manual runs on main and PRs labeled canary.
| See :ref:`howto/stability`. | ||
| """ | ||
| class _LoggingToolset(WrapperToolset[Any]): | ||
| """Wrap a toolset to log each tool call with timing; applied through ``ToolLoggingCapability``.""" |
There was a problem hiding this comment.
The Experimental note removed here didn't move to ToolLoggingCapability, which is now the module's only public class and is listed as experimental in stability.rst. Could its docstring carry the same note as the other experimental classes?
LoggingToolset is no longer exported from airflow.providers.common.ai.toolsets; tool-call logging stays available through enable_tool_logging and ToolLoggingCapability. The Experimental notes are removed from the parameters and classes that graduate to stable, and kept, with the concrete reason, on datasource_config and data_sources.
Moves managed agent toolsets, per-tool approval, ObjectStorageToolset, DecisionPolicy, pinned_arguments, llm_sql, llm_file_analysis, llm_schema_compare and the LangChain hook and bridge to the stable list, and gives every remaining experimental entry a concrete, checkable reason. Fixes the stale claim that CI does not run the Strands and ADK adapter tests.
Per-tool approval and min_confidence on a branch option are stable, so their docstrings no longer call them experimental. The toolset Layering section now describes ToolLoggingCapability as a capability that wraps the agent's toolset, the CI notes say Python source or test files to match the selective checks, and a long note in the llm_schema_compare guide is re-wrapped.
…en the framework CI job runs
The 1.0.0 note says LoggingToolset left the public API, so the Features bullet for apache#74449 should not list it as exported.
Outside canary runs the job overrides the CI image's packages and installs the newest framework release inside the exclude-newer window; canary runs (scheduled, push, manual and canary-labelled PRs) use each framework's own dependency pins.
1.0.0 is released and still exports LoggingToolset (apache#74449), so the removal note belongs under the next release. Restore LoggingToolset in the 1.0.0 export entry.
Notes for an unreleased version sit directly under the Changelog header; the release manager adds the version heading when cutting the release.
…usion pin as a dependency limit 1.0.0 shipped both parameters as stable, so the stability policy keeps them stable until the next major release. Drop their rows from the Experimental table and the Experimental notes from the operator docs.
dade363 to
dccbafc
Compare
LoggingToolsetis no longer exported fromairflow.providers.common.ai.toolsets;tool-call logging stays available through
enable_tool_loggingandToolLoggingCapability. The Experimental notes are removed from the parametersand classes that graduate to stable, and kept, with the concrete reason, on
datasource_configanddata_sources.Was generative AI tooling used to co-author this PR?
Generated-by: [Claude] following the guidelines
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.