Skip to content

Commit 6a39c85

Browse files
hangfeicopybara-github
authored andcommitted
chore: update agents.md to include versioning strategy
Adds a description for docstring and comments in the AGENTS.md and adds a section for Versioning that describes how ADK follows Semantic Versioning 2.0.0 PiperOrigin-RevId: 778667398
1 parent b04a5ce commit 6a39c85

File tree

1 file changed

+85
-0
lines changed

1 file changed

+85
-0
lines changed

AGENTS.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -112,3 +112,88 @@ Run below command:
112112
```bash
113113
$ pytest tests/unittests
114114
```
115+
116+
## Docstring and comments
117+
118+
### Comments - Explaining the Why, Not the What
119+
Philosophy: Well-written code should be largely self-documenting. Comments
120+
serve a different purpose: they should explain the complex algorithms,
121+
non-obvious business logic, or the rationale behind a particular implementation
122+
choice—the things the code cannot express on its own. Avoid comments that
123+
merely restate what the code does (e.g., # increment i above i += 1).
124+
125+
Style: Comments should be written as complete sentences. Block comments must
126+
begin with a # followed by a single space.
127+
128+
## Versioning
129+
ADK adherence to Semantic Versioning 2.0.0
130+
131+
Core Principle: The adk-python project strictly adheres to the Semantic
132+
Versioning 2.0.0 specification. All release versions will follow the
133+
MAJOR.MINOR.PATCH format.
134+
135+
### Breaking Change
136+
137+
A breaking change is any modification that introduces backward-incompatible
138+
changes to the public API. In the context of the ADK, this means a change that
139+
could force a developer using the framework to alter their existing code to
140+
upgrade to the new version. The public API is not limited to just the Python
141+
function and class signatures; it also encompasses data schemas for stored
142+
information (like evaluation datasets), the command-line interface (CLI),
143+
and the data format used for server communications.
144+
145+
### Public API Surface Definition
146+
147+
The "public API" of ADK is a broad contract that extends beyond its Python
148+
function signatures. A breaking change in any of the following areas can
149+
disrupt user workflows and the wider ecosystem of agents and tools built with
150+
ADK. The analysis of the breaking changes introduced in v1.0.0 demonstrates the
151+
expansive nature of this contract. For the purposes of versioning, the ADK
152+
Public API Surface is defined as:
153+
154+
- All public classes, methods, and functions in the google.adk namespace.
155+
156+
- The names, required parameters, and expected behavior of all built-in Tools
157+
(e.g., google_search, BuiltInCodeExecutor).
158+
159+
- The structure and schema of persisted data, including Session data, Memory,
160+
and Evaluation datasets.
161+
162+
- The JSON request/response format of the ADK API server(FastAPI server)
163+
used by adk web, including field casing conventions.
164+
165+
- The command-line interface (CLI) commands, arguments, and flags (e.g., adk deploy).
166+
167+
- The expected file structure for agent definitions that are loaded by the
168+
framework (e.g., the agent.py convention).
169+
170+
#### Checklist for Breaking Changes:
171+
172+
The following changes are considered breaking and necessitate a MAJOR version
173+
bump.
174+
175+
- API Signature Change: Renaming, removing, or altering the required parameters
176+
of any public class, method, or function (e.g., the removal of the list_events
177+
method from BaseSessionService).
178+
179+
- Architectural Shift: A fundamental change to a core component's behavior
180+
(e.g., making all service methods async, which requires consumers to use await).
181+
182+
- Data Schema Change: A non-additive change to a persisted data schema that
183+
renders old data unreadable or invalid (e.g., the redesign of the
184+
MemoryService and evaluation dataset schemas).
185+
186+
- Tool Interface Change: Renaming a built-in tool, changing its required
187+
parameters, or altering its fundamental purpose (e.g., replacing
188+
BuiltInCodeExecutionTool with BuiltInCodeExecutor and moving it from the tools
189+
parameter to the code_executor parameter of an Agent).
190+
191+
- Configuration Change: Altering the required structure of configuration files
192+
or agent definition files that the framework loads (e.g., the simplification
193+
of the agent.py structure for MCPToolset).
194+
195+
- Wire Format Change: Modifying the data format for API server interactions
196+
(e.g., the switch from snake_case to camelCase for all JSON payloads).
197+
198+
- Dependency Removal: Removing support for a previously integrated third-party
199+
library or tool type.

0 commit comments

Comments
 (0)