This is an automated email from the ASF dual-hosted git repository.

hezhangjian pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/servicecomb-website.git


The following commit(s) were added to refs/heads/master by this push:
     new 8bcf4132 docs: verify ASF publication before completing releases (#341)
8bcf4132 is described below

commit 8bcf413283ac9b7769cd8b456cfd5f85afbf3664
Author: Zhangjian He <[email protected]>
AuthorDate: Tue Nov 10 10:47:13 2026 +0800

    docs: verify ASF publication before completing releases (#341)
---
 _developers/cn/release_guide.md | 79 +++++++++++++++++---------------------
 _developers/release_guide.md    | 84 +++++++++++++++++------------------------
 2 files changed, 69 insertions(+), 94 deletions(-)

diff --git a/_developers/cn/release_guide.md b/_developers/cn/release_guide.md
index af94e442..d708f248 100755
--- a/_developers/cn/release_guide.md
+++ b/_developers/cn/release_guide.md
@@ -4,7 +4,7 @@ lang: cn
 ref: release_guide
 permalink: /cn/developers/release-guide/
 excerpt: "ServiceComb发版指南 介绍如何在Apache发版"
-last_modified_at:  2018-05-08T09:55:44+08:00
+last_modified_at: 2026-11-10T00:00:00+00:00
 author: Asif Siddiqui
 tags: [发版]
 redirect_from:
@@ -22,6 +22,28 @@ redirect_from:
 3. 
因为发版的过程中需要使用[密钥](https://www.apache.org/dev/openpgp.html#generate-key)对[发布版本进行签名](https://www.apache.org/dev/release-signing),请确保密钥中的公钥已经[发布](https://www.apache.org/dev/openpgp.html#publish-in-web-space)到公钥服务器。
 4. 熟悉maven版本发行相关的设置。
 
+## 发布批准与完成检查
+
+仅创建 Git 标签、GitHub Release 或通过投票,并不代表 Apache 正式发布已经完成。请遵循 [ASF 
发布政策](https://www.apache.org/legal/release-policy.html)和[下载页面要求](https://infra.apache.org/release-download-pages.html)。
+
+### PMC 批准要求 {#pmc-approval}
+
+- 发起投票前,检查实际待投票的签名源码包、校验和、构建与测试,以及许可证合规性(包括 `LICENSE`、`NOTICE`、ASF 
源码声明和捆绑的第三方内容)。逐项审核 RAT 结果,不能仅凭数量判断合规性。将签名公钥加入项目的 `KEYS` 文件,并使用它验证候选包。
+- 向 `[email protected]` 发送 `[VOTE]`,注明候选包地址及 SVN 修订号、Git 
标签和提交、校验和、`KEYS` 以及使用的临时仓库。
+- 发布投票 SHOULD 保持开放至少 72 小时,不能仅因已经收到三票赞成就提前结束。缩短投票时间时,投票邮件 MUST 
说明需要加急的特殊原因;偏离政策的情况 MUST 向董事会报告,通常可在下次定期报告中说明。
+- 通过投票需要至少三票来自 PMC 成员的有效 +1,且有效赞成票多于反对票。发布投票没有否决权,但需要调查反对意见,并在发布前解决违反政策的问题。
+- 向 `[email protected]` 发送 
`[RESULT]`,记录实际起止时间、有效票数、投票讨论链接和获批的具体候选包。投票通过后,不得重新构建、替换或悄悄修改已投票的制品。
+
+### 发布完成清单 {#publication-checklist}
+
+发布经理为每项保存核验依据,完成后才能将版本标记为已发布:
+
+- [ ] 将 `dist/dev/servicecomb` 中选定 RC 的获批制品、签名(`.asc`)和校验和(`.sha512`)原样移至 
`dist/release/servicecomb` 下对应组件和版本的目录。记录 SVN 修订号和制品哈希。发布经理如没有 `dist/release` 
写权限,应请有权限的 PMC 成员执行。
+- [ ] 等待分发同步,然后从 `https://downloads.apache.org/servicecomb/` 
下载每个已发布的制品、签名、校验和及项目 `KEYS`。使用已发布的公钥验证签名,检查校验和,并与获批 RC 比较。SVN 
提交成功或等待时间届满都不能代替可用性验证。通告前继续采用项目现有的 24 小时等待时间;ASF 指南要求更新下载页或发送通告前至少等待一小时。
+- [ ] 部署英文和中文下载页及发布说明。跟随 `closer.lua` 链接检查实际的当前版本文件;签名、校验和及 `KEYS` 使用指向 
`downloads.apache.org` 的 HTTPS 
直链。检查已部署页面上每个变更链接,包括准确的文件名和版本目录。不要发布不存在的可选二进制包链接。移除旧版本前,先确认其文件已在 
`archive.apache.org/dist/servicecomb/` 存档,并更新或移除受影响的链接。
+- [ ] ASF 分发与下载页面核验完成后,才发布 GitHub Release 信息,并链接到项目官方下载页。仅引导最终用户使用 ASF 
分发的正式制品,不引导至 GitHub 自动生成的源码压缩包、`dist/dev` 候选包或临时仓库。未完成的 GitHub 发布说明保持为未公开草稿。
+- [ ] 发送包含项目官方下载页链接的通告。在发布记录中保留投票及结果链接、SVN 
修订号、核验结果、已部署页面检查结果和通告链接。检查失败时先修复,不能发送通告或将发布标记为完成。
+
 ## 配置Maven
 ServiceComb Java-Chassis和Saga使用Maven进行版本发布,我们需要在发布前对Maven进行一些配置。
 
@@ -68,7 +90,7 @@ gvt restore
 
 2. 在master分支上打上准备发布版本的标签。
 
-3. 运行RAT工具,检查所有源文件头都有合法的ASF声明, 
请参考[该文档](https://github.com/apache/servicecomb-service-center/tree/master/docs/release)。
+3. 运行 RAT,并根据前述许可证检查要求逐项审核结果,区分 ASF 
源码和捆绑的第三方内容。请参考[该文档](https://github.com/apache/servicecomb-service-center/tree/master/docs/release)。
 
 4. 
运行`make_release.sh`脚本,请参考[该文档](https://github.com/apache/servicecomb-service-center/tree/master/scripts/release)。
 
@@ -94,23 +116,11 @@ gvt restore
 
 ***PMC批准***
 
-14. 发送投票邮件至 ***[email protected]***, 发起PMC批准.
-
-15. 等待72小时,或者获得3票+1并且没有-1。如果有-1票,修正问题并从***第1步***重新开始。
-
-16. 将投票结果发布到[email protected]。
+遵循 [PMC 批准要求](#pmc-approval),完成候选包核验、投票及结果邮件。
 
 ***通告***
 
-20. 
上传发行包至[Apache发行仓库](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-service-center/)。
-
-21. 等待24小时,让所有镜像同步。
-
-22. 
将[dev](https://dist.apache.org/repos/dist/dev)的文件移动到[release](https://dist.apache.org/repos/dist/release)目录中,同时确认已经被存档,同时更新网站上相关链接。
-
-23. 上传发行页面至ServiceComb网站。
-
-24. 发送发行通告邮件到[email protected], [email protected]。
+依次完成[发布完成清单](#publication-checklist):将获批候选包发布到 [Apache 
发行仓库](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-service-center/),核验
 ASF 下载,部署并检查官网,再发布 GitHub Release 信息,向 `[email protected]` 和 
`[email protected]` 发送通告。
 
 
 ## 发行Java-Chassis
@@ -178,7 +188,7 @@ gvt restore
     根据时间找到最近的java-chassis相关的记录,close该条记录,得到maven临时仓库的链接,例
     
如:`https://repository.apache.org/content/repositories/orgapacheservicecomb-1385`。
 
-8. 在 servicecomb-java-chassis 的 github 的 release 页面,点击 release, 发布 pre release 
版本, 打上 tag 。
+8. 将发布说明保存为未公开的 GitHub 草稿。不要发布 GitHub pre-release,也不要引导最终用户使用候选包。
 
 * ***给发行包签名***
 
@@ -218,39 +228,18 @@ gvt restore
 
 * ***PMC批准***
 
-1. 发送投票邮件至 ***[email protected]***, 发起PMC批准.
-
-2. 等待72小时,或者获得3票+1并且没有-1。如果有-1票,修正问题,重新开始版本发布流程(视具体的失败情况,可能
-    需要重新生成 release notes,删除svn临时文件,删除临时`Staging repositories`等)。
-
-3. 将投票结果发布到[email protected]。
+遵循 [PMC 批准要求](#pmc-approval),完成候选包核验、投票及结果邮件。
 
 * ***更新文档和通告***
 
-1. 在 servicecomb-java-chassis 的 github 的 release 页面,将 pre release 修改为正式 
release。完成 release notes书写。
-
-2. 将 [dev](https://dist.apache.org/repos/dist/dev) 的文件移动到 
[release](https://dist.apache.org/repos/dist/release) 目录中。
+1. 仅将选定且获批 RC 的制品、签名和校验和原样移至 [Apache 
发行仓库](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-java-chassis/)对应版本目录。不要复制所有
 RC 目录,也不要从 Git 标签重新构建。
 
-        ```
-        cp dev/servicecomb/servicecomb-java-chassis/2.0.0/* 
release/servicecomb/servicecomb-java-chassis/2.0.0/
-        cd release/servicecomb/servicecomb-java-chassis/
-        svn add 2.0.0
-        svn ci 2.0.0
-        ```
-
-    同时删除 [dev](https://dist.apache.org/repos/dist/dev) 的临时内容。
-
-        ```
-        svn rm 1.2.0
-        svn ci .
-        ```
+2. 完成[发布完成清单](#publication-checklist)中的分发核验。在已发布文件验证成功前,保留临时候选包。
 
-3. 使用apache帐号登录到 [Apache Nexus](https://repository.apache.org/),点击 “Staging 
Repositories” ,搜索 “servicecomb” ,
-    找到需要发布的 java-chassis 记录,点击 “Release” 。 如果由其他临时 “Staging Repositories” 
,可以点击 “Drop” 一并删除。
+3. 使用 Apache 帐号登录 [Apache 
Nexus](https://repository.apache.org/),发布投票邮件中明确指定的、已关闭的临时仓库,不能仅按时间选择最新仓库。Maven 
发布不能代替 ASF 源码分发。
 
-4. 等待24小时,让所有镜像同步。
+4. 部署并核验中英文官网的下载页和发布说明。页面结构可参考 [1.3.0 
PR](https://github.com/apache/servicecomb-website/pull/210) 或 [2.0.0 
PR](https://github.com/apache/servicecomb-website/pull/240),但应使用当前待发布版本已验证的链接。清理旧版本前,确认存档并更新受影响的链接。
 
-5. 更新官网发布信息。 修改内容可以参考 [1.3.0 
RP](https://github.com/apache/servicecomb-website/pull/210)
-    或者 [2.0.0 RP](https://github.com/apache/servicecomb-website/pull/240)
+5. ASF 下载核验和网站部署完成后,再发布 GitHub Release 信息,并链接到项目官方下载页。
 
-6. 发送发行通告邮件到 `[email protected]`, `[email protected]`。
+6. 完成清单中的通告和记录事项,所有检查通过后才向 `[email protected]` 和 
`[email protected]` 发送通告。
diff --git a/_developers/release_guide.md b/_developers/release_guide.md
index c8c4a5f0..899e54c3 100755
--- a/_developers/release_guide.md
+++ b/_developers/release_guide.md
@@ -4,7 +4,7 @@ lang: en
 ref: release_guide
 permalink: /developers/release-guide/
 excerpt: "Release guide for doing the releases in Apache"
-last_modified_at: 2018-04-03T18:33:43+08:00
+last_modified_at: 2026-11-10T00:00:00+00:00
 author: Asif Siddiqui
 tags: [release]
 redirect_from:
@@ -22,6 +22,28 @@ To prepare or perform a released you MUST BE at least an 
Apache ServiceComb comm
 3. Should have [Sign 
Key](https://www.apache.org/dev/openpgp.html#generate-key) for [signing the 
release](https://www.apache.org/dev/release-signing), the keys should be 
published to public key server.
 4. Get familiar with the release settings in the parent Apache POM
 
+## Release approval and completion
+
+A Git tag, GitHub release or successful vote alone does not complete an Apache 
release. Follow the [ASF release 
policy](https://www.apache.org/legal/release-policy.html) and [download page 
requirements](https://infra.apache.org/release-download-pages.html).
+
+### PMC approval
+
+- Before calling the vote, verify the exact signed source package, its 
checksum, build and tests, and licensing (including `LICENSE`, `NOTICE`, ASF 
source headers and bundled third-party material). Review RAT findings; a count 
alone is not a licensing decision. Publish the signing public key in the 
project's `KEYS` file and verify the candidate with it.
+- Start a `[VOTE]` on `[email protected]` identifying the candidate 
URL and SVN revision, Git tag/commit, checksums, `KEYS` and any staging 
repository.
+- Release votes SHOULD remain open for at least 72 hours. Do not close early 
merely because three positive votes have arrived. A shorter vote call MUST 
explain the exceptional reason for expediting it, and policy deviations MUST be 
reported to the Board, normally in the next scheduled report.
+- Approval requires at least three binding +1 votes from PMC members and more 
binding positive than negative votes. Release votes cannot be vetoed; 
investigate negative votes and resolve policy violations before publication.
+- Post a `[RESULT]` to `[email protected]` with the actual opening 
and closing times, binding tally, vote thread and exact approved candidate. Do 
not rebuild, replace or silently change the voted packages after approval.
+
+### Publication checklist
+
+The release manager records the evidence for each item before calling the 
release complete:
+
+- [ ] Promote the exact approved packages, signatures (`.asc`) and checksums 
(`.sha512`) from the selected RC under `dist/dev/servicecomb` to the 
component/version directory under `dist/release/servicecomb`. Record the SVN 
revision and artifact hashes. If the release manager cannot write to 
`dist/release`, ask an authorized PMC member to publish it.
+- [ ] Wait for distribution synchronization, then download every published 
package, signature, checksum and the project `KEYS` from 
`https://downloads.apache.org/servicecomb/`. Verify signatures with the 
published key, verify checksums, and compare the packages with the approved RC. 
An SVN commit or elapsed waiting period alone is not proof of availability. 
Keep the existing 24-hour project waiting period before announcing; ASF 
guidance requires at least one hour before updating the down [...]
+- [ ] Deploy the English and Chinese download pages and release notes. Follow 
`closer.lua` links through to the actual current-release files; link 
signatures, checksums and `KEYS` directly over HTTPS to `downloads.apache.org`. 
Check every changed link on the deployed pages, including exact filenames and 
version directories. Do not publish links to missing optional binaries. Before 
removing an old release, verify its files in 
`archive.apache.org/dist/servicecomb/` and update or remove aff [...]
+- [ ] Only after the ASF distribution and download pages are verified, publish 
any GitHub release metadata with links to the official project download page. 
Direct end users only to ASF-distributed releases, not GitHub-generated source 
archives, `dist/dev` candidates or staging repositories. Keep unfinished GitHub 
release notes as an unpublished draft.
+- [ ] Send the announcement with the official project download-page link. 
Retain the vote/result links, SVN revision, verification results, deployed-page 
checks and announcement link in the release record. If a check fails, fix it 
before announcing or marking the release complete.
+
 ## Maven 2 Setup
 As ServiceComb Java Chassis and Saga are using maven for the release, you 
should do some maven 2 setup before releasing these two projects.
 Before you deploy anything to the maven repository using Maven 2, you should 
configure your ~/.m2/settings.xml file so that the file permissions of the 
deployed artifacts are group writable. If you do not do this, other developers 
will not able to overwrite your SNAPSHOT releases with newer versions. The 
settings follow the 
[guidelines](http://maven.apache.org/developers/committer-settings.html) used 
by the Maven project. Please pay particular attention to the [password 
encryption recomm [...]
@@ -89,7 +111,7 @@ gvt restore
 
 2. Create a Tag from the master branch based on the version number which needs 
to be released.
 
-3. Run RAT tool to ensure no license issues are there, follow the guide over 
[here](https://github.com/apache/servicecomb-service-center/tree/master/docs/release)
+3. Run RAT and review its findings against the licensing checks above, 
including the distinction between ASF source and bundled third-party material. 
Follow the guide 
[here](https://github.com/apache/servicecomb-service-center/tree/master/docs/release).
 
 4. Run the make_release.sh to make the release for windows and linux following 
the guide over 
[here](https://github.com/apache/servicecomb-service-center/tree/master/scripts/release).
 
@@ -117,23 +139,11 @@ gvt restore
 
 ***PMC Approval***
 
-1. Send the voting mail in ***[email protected]*** for 1PMC approval.
-
-2. Wait for 72 hours or unless you get 3 +1 binding vote with no -1 vote. If 
you get even one -1 binding vote then fix the issue and start again from 
***Step 1***.
-
-3. Publish the result of the vote in [email protected].
+Follow [PMC approval](#pmc-approval), including candidate verification, vote 
duration and the result email.
 
 ***Announcements***
 
-1. Upload the releases to [Apache release 
repository](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-service-center/).
-
-2. Wait for 24 hours to replicate the release in all the mirrors.
-
-3. Delete old releases from [dev](https://dist.apache.org/repos/dist/dev) and 
[release] (https://dist.apache.org/repos/dist/release) and check for the old 
release in archive, update the same links in the website for old releases.
-
-4. Upload the release page of ServiceComb Website.
-
-5. Send the announcement mails to [email protected], 
[email protected]
+Complete the [publication checklist](#publication-checklist) in order: publish 
the approved candidate to the [Apache release 
repository](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-service-center/),
 verify ASF downloads, deploy and check the website, then publish GitHub 
release metadata and send announcements to `[email protected]` and 
`[email protected]`.
 
 
 ## Major Steps for doing Java-Chassis Release
@@ -196,7 +206,7 @@ Prepare Linux environment, and make sure can upload 
artifacts to maven central.
    log in to  [Apache Nexus](https://repository.apache.org/). Click  `Staging 
Repositories`, search `servicecomb`,
    find the latest repository, click "close", and get the staging repository 
link like 
`https://repository.apache.org/content/repositories/orgapacheservicecomb-1385`
 
-8. In servicecomb-java-chassis  release page,click release, do a `pre release`
+8. Prepare the release notes as an unpublished GitHub draft. Do not publish a 
GitHub pre-release or direct end users to the candidate.
 
 ***Sign the distributions***
 
@@ -234,44 +244,20 @@ Prepare Linux environment, and make sure can upload 
artifacts to maven central.
 
 5. download the files and verify the sign.
 
-***Sending mail for permission***
-
-1. Send mail to `[email protected]` and waiting for voting result.
-
-2. Waiting 72 hours and if got three + 1 and no -1, the voting is successful. 
If there are some problems,
-    start a new round of release. (According to the problem, please notice to 
clean up release notes,
-    temporary svn files, and temporary stating repositories. )
-
-3. Send the voting result to `[email protected]`
+***PMC Approval***
 
+Follow [PMC approval](#pmc-approval), including candidate verification, vote 
duration and the result email.
 
 ***Update documents and announcements***
 
-1. In servicecomb-java-chassis  github release page,set `pre release` to 
`formal release` and write release notes.
+1. Promote only the selected approved RC's packages, signatures and checksums 
to the version directory in the [Apache release 
repository](https://dist.apache.org/repos/dist/release/servicecomb/servicecomb-java-chassis/).
 Do not copy all RC directories or rebuild from a Git tag.
 
-2. Move [dev](https://dist.apache.org/repos/dist/dev) to 
[release](https://dist.apache.org/repos/dist/release)
- 
-        ```
-        cp dev/servicecomb/servicecomb-java-chassis/2.0.0/* 
release/servicecomb/servicecomb-java-chassis/2.0.0/
-        cd release/servicecomb/servicecomb-java-chassis/
-        svn add 2.0.0
-        svn ci 2.0.0
-        ```
-        
-    And delete [dev](https://dist.apache.org/repos/dist/dev)
-    
-        ```
-        svn rm 1.2.0
-        svn ci .
-        ```
+2. Complete the distribution checks in the [publication 
checklist](#publication-checklist). Keep the staged candidate until the 
published files have been verified.
 
-3. Log in to [Apache Nexus](https://repository.apache.org/), find `Staging 
Repositories` and search 
-    `servicecomb`,find the last `closed` repository, and click `release`. If 
there are any temporary `Staging Repositories`,
-    `drop` them. 
+3. Log in to [Apache Nexus](https://repository.apache.org/) and release the 
exact closed staging repository identified in the vote. Do not select a 
repository merely because it is the latest one. Maven publication does not 
replace ASF source distribution.
 
-4. Waiting for 24 hour for all mirror in sync.
+4. Deploy and verify the English and Chinese website download pages and 
release notes. See [1.3.0 
PR](https://github.com/apache/servicecomb-website/pull/210) or [2.0.0 
PR](https://github.com/apache/servicecomb-website/pull/240) for the website 
structure; use verified URLs for the version being released. Verify archival 
and update affected links before cleaning up old releases.
 
-5. Update the servicecomb-website, see [1.3.0 
RP](https://github.com/apache/servicecomb-website/pull/210)
-or [2.0.0 RP](https://github.com/apache/servicecomb-website/pull/240)
+5. After the ASF download checks and website deployment pass, publish the 
GitHub release notes with the official project download-page link.
 
-6. Send announcements to `[email protected]`, `[email protected]`。
+6. Complete the announcement and evidence items in the publication checklist, 
sending announcements to `[email protected]` and 
`[email protected]` only after the checks pass.

Reply via email to