publishing

npm

npm 软件包通过 CI/CD 发布在.github/workflows/deploy_packages.yml.每次合并到 master 的提交都会检查所有公共软件包的新版本，任何新版本都会自动发布到 npm。

版本发布由变更集处理，每当合并 "版本包 "PR 时就会触发变更集。这通常在欧洲中部时间每周二中午左右进行。

PR Checks: Notify the teams & ensure there are no outstanding PRs pending to be merged for this version. This should be done in time to ensure a smooth release day. If there are any, reach out to maintainers and relevant owners of the affected code reminding them of the deadline for the release. * Lock main branch - Lock the main branch to prevent any new merges by other maintainers. Do not unlock the main branch until the release was published successfully - Core maintainers can still merge last PRs using their admin override including the Version Packages PR - Note: Admin rights are required to lock the branch. If you lack the necessary permissions, contact a core maintainer to perform this action on your behalf. * Check Version Packages (next) Pull Request - Verify the version we are shipping is correct, by looking at the version packages PR title. It should be "Version Packages (next)" - Ch

合并Version Packages (next)拉取请求将触发部署工作流程。请按照部署工作流程如果发现不稳定(例如，构建过程不稳定或发布步骤在向 npm 发布时遇到错误)，只需重启工作流程即可。

恭喜发布！现在应该在#announcements一旦在 Discord 上发出通知，您就可以解锁主分支并完成发布。

主线发布的其他步骤

Switch Release Mode to exit pre-release mode. This can be done at any time after the last Next Line Release. - Check .changeset/pre.json if the mode is set to exit. If you encounter mode: "pre" it indicates a next line release. * Check Version Packages Pull Request - Check for mentions of "major" & "breaking" and if they are expected in the current release - Verify the version we are shipping is correct * Create Release Notes - There exists a release notes template for creating the release notes. It can already be created after the last main line release to keep track of major changes during the month - The content is picked by relevancy showcasing the work of the community during the month of the release - Mention newly added packages or features - Mention any securi

发布版本后，在GitHub 存储库并用版本说明替换文本内容。

要进入预发布模式： yarn changeset pre enter next 并创建 PR + 合并修改 * 要退出预发布模式： yarn changeset pre exit 并创建 PR + 合并修改 - 必须在主线发布之前完成 * 时间并不重要；会影响下一次发布的发生

本紧急发布程序仅适用于Backstage维护者。

给定一个或多个我们要为其创建补丁发布的主 PR，从 repo 根目录运行以下脚本

./scripts/patch-release-for-pr.js <pr-number> <pr-number-2> ...

等待脚本执行完毕，在输出的末尾你会发现一个链接，格式为https://github.com/backstage/backstage/compare/patch/...在浏览器中打开此链接，创建补丁发布的 PR。完成 "此版本修复了......的问题 "这句话，然后创建 PR。

一旦 PR 获得批准并合并，补丁发布就会自动创建。当通知发布到 Discord 的#announcements密切关注 "部署软件包 "工作流，如果失败则重新触发。重新触发此工作流的任何部分都是安全的，包括发布步骤。

如果上述过程失败，您可以回到下面记录的手动过程。

这是我们在使用补丁脚本之前使用的老式手动流程，在此提供作为参考：

在本例中，我们将使用@backstage/plugin-foo软件包为例，假定它当前的版本是6.5.0在主分支中。

如果在版本6.5.0的@backstage/plugin-foo在v1.18.0Backstage发布，以下流程用于将紧急修复作为版本发布6.5.1在发布的补丁中v1.18.1:

Identify the release or releases that need to be patched. We should always patch the most recent major or minor main-line release if needed, which in this example would be v1.18.0. The fix may also need backporting to older major versions, in which case we will want to patch the main-line release just before the one that bumped the package to each new major version. * [ ] Repeat the following steps for each release that needs to be patched: - [ ] Make sure a patch branch exists for the release that is being patched. If a patch already exists, reuse the existing branch. The branch must always be named exactly patch/<release>. bash git checkout v1.18.0 git checkout -b patch/v1.18.0 git push --set-upstream origin patch/v1.18.0 - [ ] With the patch/v1.18.0 branch as a base, create a new branch for your fix. This branch can be named anything, but the following naming pattern may be suitable: bash git checkout -b ${USER}/plugin-foo-v1.18.0-fix - [ ] Create a single commit that applies

请维护者触发部署软件包工作流中设置了 "无条件触发发布任务运行 "复选框，在master请首先确认，在最初的发布尝试失败后，没有任何实质性内容被推送到主干分支！因此，在每次发布前锁定主干分支是明智之举。