changelog

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create changelog files for the important commits in this PR. The PR number is provided as an argument.

为本次PR中的重要提交创建变更日志文件。PR编号会作为参数提供。

Instructions

操作说明

Skip changelog for: documentation-only, internal refactoring, test-only, CI changes.
First, check what commits are on the current branch compared to main:
```
git log main..HEAD --oneline
```
For each significant change, create a changelog file in the
```
changelog/
```
folder using the format: Allowed types:
```
added
```
,
```
changed
```
,
```
deprecated
```
,
```
removed
```
,
```
fixed
```
,
```
security
```
,
```
performance
```
,
```
other
```
- ```
{PR_NUMBER}.added.md
```
  - for new features
- ```
{PR_NUMBER}.added.2.md
```
  ,
```
{PR_NUMBER}.added.3.md
```
  - for additional entries of the same type
- ```
{PR_NUMBER}.changed.md
```
  - for changes to existing functionality
- ```
{PR_NUMBER}.fixed.md
```
  - for bug fixes
- ```
{PR_NUMBER}.deprecated.md
```
  - for deprecations
- ```
{PR_NUMBER}.removed.md
```
  - for removed features
- ```
{PR_NUMBER}.security.md
```
  - for security fixes
- ```
{PR_NUMBER}.performance.md
```
  - for performance improvements
- ```
{PR_NUMBER}.other.md
```
  - for other changes
Each changelog file should at least contain a main single line starting with
```
- 
```
followed by a clear description of the change. No line wrapping.
If the change is complicated, changelog files can have indented lines after the main line with additional details or code samples.
Use ⚠️ emoji prefix for breaking changes.
Write changes in user-facing terms first. Lead with what users of the framework will notice: new APIs, changed behavior, new parameters, fixed bugs they might have hit, etc. Implementation details (internal refactoring, how something is wired up under the hood) can be included as secondary context after the user-facing description, but should never be the only content of a changelog entry when there is a user-visible effect.

Good (user-facing first, implementation detail as context):
```
- Turn completion instructions now persist correctly across full context updates when using `system_instruction`. Previously they were injected as a context system message, which caused warning spam and didn't survive context updates.
```
Bad (implementation detail only, no user-facing framing):
```
- Fixed turn completion instructions being injected as a context system message instead of using `system_instruction`.
```
Ask yourself: "If I'm a developer building on Pipecat, what would I notice changed?" Start there.

以下情况无需生成变更日志：仅文档更新、内部重构、仅测试代码修改、CI配置变更。
首先，对比main分支，查看当前分支的提交记录：
```
git log main..HEAD --oneline
```
对于每一项重要变更，在
```
changelog/
```
文件夹中创建变更日志文件，格式规则如下：允许的类型：
```
added
```
（新增功能）、
```
changed
```
（功能变更）、
```
deprecated
```
（弃用）、
```
removed
```
（移除功能）、
```
fixed
```
（修复问题）、
```
security
```
（安全修复）、
```
performance
```
（性能优化）、
```
other
```
（其他变更）
- ```
{PR_NUMBER}.added.md
```
  - 用于记录新增功能
- ```
{PR_NUMBER}.added.2.md
```
  、
```
{PR_NUMBER}.added.3.md
```
  - 用于记录同类型的额外条目
- ```
{PR_NUMBER}.changed.md
```
  - 用于记录现有功能的变更
- ```
{PR_NUMBER}.fixed.md
```
  - 用于记录Bug修复
- ```
{PR_NUMBER}.deprecated.md
```
  - 用于记录弃用内容
- ```
{PR_NUMBER}.removed.md
```
  - 用于记录移除的功能
- ```
{PR_NUMBER}.security.md
```
  - 用于记录安全修复
- ```
{PR_NUMBER}.performance.md
```
  - 用于记录性能优化
- ```
{PR_NUMBER}.other.md
```
  - 用于记录其他变更
每个变更日志文件至少包含一行以
```
- 
```
开头的内容，后跟清晰的变更描述，请勿换行。
如果变更内容复杂，可在主行下方添加缩进的行，补充详细说明或代码示例。
对于破坏性变更，需以⚠️表情符号作为前缀。
优先使用面向用户的表述。首先说明框架用户会注意到的内容：新API、变更的行为、新增参数、修复的用户可能遇到的Bug等。实现细节（内部重构、底层实现逻辑）可作为补充信息放在面向用户的描述之后，但当变更对用户可见时，绝不能仅记录实现细节。

示例（良好）（先面向用户，再补充实现细节）：
```
- 现在，当使用`system_instruction`时，回合完成指令会在完整上下文更新后正确保留。此前这些指令会被作为上下文系统消息注入，导致警告信息泛滥且无法在上下文更新后保留。
```
示例（不佳）（仅记录实现细节，无面向用户的表述）：
```
- 修复了回合完成指令被作为上下文系统消息注入而非使用`system_instruction`的问题。
```
请自问：“如果我是基于Pipecat进行开发的开发者，我会注意到哪些变化？”从这个角度出发撰写内容。

Example

示例

For PR #3519 with a new feature and a bug fix:

changelog/3519.added.md

- Added `SomeNewFeature` for doing something useful.

changelog/3519.fixed.md

- Fixed an issue where something was not working correctly in some user-visible scenario. The root cause was an internal implementation detail.

以包含新增功能和Bug修复的PR #3519为例：

changelog/3519.added.md

- 新增`SomeNewFeature`，用于实现某类实用功能。

changelog/3519.fixed.md

- 修复了某场景下功能无法正常工作的问题。根本原因是某内部实现细节存在问题。