release

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ActivityPub Release Process

ActivityPub 版本发布流程

Quick reference for managing releases and changelogs for the WordPress ActivityPub plugin.
WordPress ActivityPub插件的版本发布与变更日志管理速查指南。

Quick Reference

速查指南

Release Commands

发布命令

bash
npm run release              # Create major/minor release PR.
bash
npm run release              # 创建主版本/次版本发布PR。

Version File Locations

版本文件位置

When updating versions manually, change these files:
  • activitypub.php
    - Plugin header (
    Version: X.Y.Z
    ).
  • readme.txt
    - WordPress.org readme (
    Stable tag: X.Y.Z
    ).
  • package.json
    - npm version (
    "version": "X.Y.Z"
    ).
  • CHANGELOG.md
    - Changelog file (auto-updated by release script).
手动更新版本时,需修改以下文件:
  • activitypub.php
    - 插件头部(
    Version: X.Y.Z
    )。
  • readme.txt
    - WordPress.org 说明文档(
    Stable tag: X.Y.Z
    )。
  • package.json
    - npm 版本号(
    "version": "X.Y.Z"
    )。
  • CHANGELOG.md
    - 变更日志文件(由发布脚本自动更新)。

Comprehensive Release Guide

完整发布指南

See Release Process for complete release workflow and detailed steps.
查看发布流程获取完整的发布工作流和详细步骤。

Release Workflow

发布工作流

Major/Minor Releases

主版本/次版本发布

Quick workflow:
bash
undefined
快速工作流:
bash
undefined

1. Run release script from plugin root.

1. 从插件根目录运行发布脚本。

npm run release
npm run release

Script automatically:

脚本将自动执行:

- Determines version from changelog entries.

- 根据变更日志条目确定版本号。

- Updates version numbers in all files.

- 更新所有文件中的版本号。

- Updates CHANGELOG.md.

- 更新 CHANGELOG.md。

- Creates PR for review.

- 创建用于审核的PR。

2. Review and merge the release PR.

2. 审核并合并发布PR。

3. Create GitHub release from trunk using the new tag.

3. 使用新标签从主干分支创建GitHub版本。


See [Release Process - Major/Minor](docs/release-process.md) for detailed steps.

查看[发布流程 - 主版本/次版本](docs/release-process.md)获取详细步骤。

Patch Releases

补丁版本发布

Quick workflow:
bash
undefined
快速工作流:
bash
undefined

1. Create branch from the tag to patch.

1. 基于要打补丁的标签创建分支。

git fetch --tags git checkout -b tags/5.3.1 5.3.0 # Patch 5.3.0 -> 5.3.1
git fetch --tags git checkout -b tags/5.3.1 5.3.0 # 为5.3.0版本打补丁,升级为5.3.1

2. Cherry-pick merge commits from trunk (note -m 1 flag).

2. 从主干分支挑选合并提交(注意使用-m 1参数)。

git cherry-pick -m 1 <commit-hash>
git cherry-pick -m 1 <commit-hash>

3. Update changelog and versions.

3. 更新变更日志和版本号。

composer changelog:write
composer changelog:write

Manually update versions in:

手动更新以下文件中的版本号:

- activitypub.php

- activitypub.php

- readme.txt

- readme.txt

- package.json

- package.json

4. Push branch and create GitHub release.

4. 推送分支并创建GitHub版本。

git push -u origin tags/5.3.1

**Important:** Use `-m 1` flag when cherry-picking merge commits to select the mainline parent.

See [Release Process - Patch Releases](docs/release-process.md#patch-releases) for detailed steps.
git push -u origin tags/5.3.1

**重要提示:** 挑选合并提交时请使用`-m 1`参数,以选择主线父提交。

查看[发布流程 - 补丁版本](docs/release-process.md#patch-releases)获取详细步骤。

Changelog Management

变更日志管理

How It Works

工作机制

Changelogs are managed automatically through the PR workflow:
  1. PR Template (
    .github/PULL_REQUEST_TEMPLATE.md
    ):
    • Check "Automatically create a changelog entry" checkbox.
    • Select significance: Patch/Minor/Major.
    • Select type: Added/Fixed/Changed/Deprecated/Removed/Security.
    • Write message ending with punctuation!
  2. GitHub Action (
    .github/workflows/changelog.yml
    ):
    • Creates changelog file from PR description.
    • Validates proper punctuation.
    • Saves to
      .github/changelog/
      directory.
  3. Release Process:
    • npm run release
      aggregates all entries.
    • Updates
      CHANGELOG.md
      and
      readme.txt
      automatically.
变更日志通过PR工作流自动管理:
  1. PR模板
    .github/PULL_REQUEST_TEMPLATE.md
    ):
    • 勾选“自动创建变更日志条目”复选框。
    • 选择重要性:补丁/次版本/主版本。
    • 选择类型:新增/修复/变更/弃用/移除/安全。
    • 撰写消息必须以标点符号结尾!
  2. GitHub Action
    .github/workflows/changelog.yml
    ):
    • 根据PR描述创建变更日志文件。
    • 验证标点符号是否符合要求。
    • 保存至
      .github/changelog/
      目录。
  3. 发布流程
    • npm run release
      汇总所有条目。
    • 自动更新
      CHANGELOG.md
      readme.txt

Critical Requirements

关键要求

Always end changelog messages with punctuation:
✅ Add support for custom post types.
✅ Fix signature verification bug.
❌ Add support for custom post types
❌ Fix signature verification bug
Write end-user friendly messages:
  • Focus on user benefit, not implementation details.
  • Avoid technical jargon where possible.
  • Describe what users can now do, not how it works internally.
✅ Add pre-built block patterns for easy profile and sidebar setup.
✅ Fix follow button not appearing on author pages.
❌ Add register_patterns() method to class-blocks.php.
❌ Refactor User class to use Actors collection.
Never mention AI tools or coding assistants in changelog messages.
See PR Workflow - Changelog for complete changelog requirements.
变更日志消息必须始终以标点符号结尾:
✅ 新增自定义文章类型支持。
✅ 修复签名验证漏洞。
❌ Add support for custom post types
❌ Fix signature verification bug
撰写面向终端用户的友好消息:
  • 聚焦用户收益,而非实现细节。
  • 尽可能避免技术术语。
  • 描述用户现在可以做什么,而非内部工作原理。
✅ 新增预构建区块模式,简化个人资料和侧边栏设置。
✅ 修复作者页面未显示关注按钮的问题。
❌ Add register_patterns() method to class-blocks.php.
❌ Refactor User class to use Actors collection.
变更日志消息中绝不能提及AI工具或代码助手。
查看PR工作流 - 变更日志获取完整的变更日志要求。

Version Numbering

版本号规则

Semantic versioning:
  • Major (X.0.0) - Breaking changes.
  • Minor (0.X.0) - New features, backward compatible.
  • Patch (0.0.X) - Bug fixes only.
The release script determines version automatically from changelog entry significance levels.
语义化版本控制:
  • 主版本(X.0.0) - 包含破坏性变更。
  • 次版本(0.X.0) - 新增功能,向后兼容。
  • 补丁版本(0.0.X) - 仅包含Bug修复。
发布脚本会根据变更日志条目的重要性级别自动确定版本号。