版本发布¶
本页面旨在帮助核心开发者发布新版本的aeon。
核心开发者在发布版本时应该拥有对仓库的写权限。
aeon 目前的目标是每一到两个月发布一次，基于可用于发布的新内容的数量。
准备发布版本¶
发布过程如下，从高层次来看：
确保执行弃用操作。 对于某个版本的弃用操作应在代码中用“版本号”注释标记。例如，对于发布
0.10.0，在代码中搜索字符串0.10.0并执行描述的弃用操作。执行弃用操作的PR应以[DEP]开头并使用deprecation标签。这样它们会被放在发布说明的“弃用”部分。创建一个“发布”拉取请求。 从主分支创建一个分支，并以发布版本命名PR。这应该会更改版本号（根目录下的
__init__.py、README.md和pyproject.toml） 并在changelog网页中提供完整的发布说明。有关更多详细信息，请参阅发布说明部分。合并“发布”拉取请求。 这个PR理想情况下应该是发布前最后的PR，除了任何必要的故障排除PR。PR和发布说明最好由多个核心开发者审查，然后在测试通过后合并。
创建GitHub发布。 此发布应创建一个遵循语法v[主版本].[次版本].[修订版本]的新标签， 例如，版本
0.10.0的字符串v0.10.0。发布名称应类似为aeon v0.10.0。GitHub发布说明应仅包含“亮点”、 “新贡献者”和“所有贡献者”部分，并链接到变更日志中的发布说明， 遵循当前GitHub发布说明的模式。还可以包括发布之间的完整GitHub提交日志。
pypi 发布和发布验证¶
创建GitHub发布触发了pypi发布工作流程。
等待
pypi发布的CI/CD完成。 如果测试由于偶发的无关失败而失败，请重新启动。如果测试确实失败， 上述步骤中出了问题，请调查、修复并重复。如果错误是已知且偶发的（即无法从外部源读取数据）， 可以重新启动发布工作流。不需要创建新的GitHub发布，如果需要更多的PR， 可以从GitHub Actions标签手动运行工作流。发布工作流完成的任务。 一旦发布工作流通过，检查
aeon在pypi上的版本，这应该是新版本。应该根据安装说明在新的Python环境中进行aeon的验证性安装。如果安装不成功或轮子没有上传，必须采取行动进行诊断和补救。
conda-forge 发布和发布验证¶
合并
conda-forge版本的PR。 一段时间后，PR将自动在aeon conda-forge feedstock中创建。 按照PR中的说明进行合并，确保更新所有已更改的依赖项和依赖版本限制。
发布说明¶
通常，发布说明应遵循以往发布说明的一般模式。初始变更说明可以通过运行.github/utilities/changelog_generator.py生成。根据标签，拉取请求将被放入发布说明的各个部分，因此请确保PR被正确标记。
生成初始发布说明后，请确保：
在发布说明的顶部添加发布版本和发布的月份/年份
如果适用，请在发布说明的顶部添加任何重要公告
添加发布亮点部分
整理自动生成的PR列表，根据需要移动PR，以便它们被正确分类。重新标记PR并重新生成发布说明可能会更容易。
确保贡献者部分是正确的
紧急发布工作流程¶
如果需要紧急发布，可以通过运行“快速发布”工作流程来加快发布测试过程。在正常情况下不应使用此工作流程。如果可能，任何发布测试的问题都应在正常的发布工作流程中解决。在任何情况下运行此流程之前，请在Slack上咨询核心开发人员。