这个发布指南在很大程度上受到了Hipparchus发布指南的启发。它列出了过去发布Orekit新版本所使用的步骤。
如果有疑问，请在论坛的“Orekit开发”部分提问。
可以发布三种类型的版本：
由于次要/主要版本和补丁版本之间的发布过程存在一些差异，因此本指南分为两个不同的部分。
第一部分介绍发布主要/次要版本的步骤，而第二部分专门介绍补丁版本，并主要列出了两个发布过程之间的差异。
0802AB8C87B0B1AEC1C1C5871550FDBD6375C33B如果需要帮助，请在Orekit论坛的开发部分提问。
一旦您拥有了SonaType OSS账户，相应的凭据必须在$HOME/.m2/settings.xml文件的servers部分中设置，使用ossrh作为id：
<servers>
<server>
<id>ossrh</id>
<username>连接到OSS网站的用户名</username>
<password>加密的密码</password>
</server>
</servers>
使用mvn -ep生成加密密码。
Graphviz用于生成站点的UML图表（参见/src/design/*.puml文件）。
Graphviz（dot）2.39及以上在生成的图表中放置了太多的空白空间。该错误尚未在graphviz中修复，因此我们必须使用2.38或更早的版本。CentOS 7中的版本可用，Ubuntu 18.04中的版本不可用。
在进行任何操作之前，请在持续集成网站上检查develop分支的状态是否良好：
如果有问题，请先修复警告和错误！
还需要在Gitlab CI/CD上检查develop分支的状态是否良好（即所有阶段都通过）。
发布将在专用分支上进行，而不是直接在主分支或develop分支上进行。因此，必须创建一个新的分支，并用于其他所有操作：
git branch release-X.Y
git checkout release-X.Y
发布是更新Maven插件版本的好机会。它们都集中在orekit/pom.xml文件中的一组属性中：
<!-- 项目特定的插件版本 -->
<orekit.spotbugs-maven-plugin.version>3.1.11</orekit.spotbugs-maven-plugin.version>
<orekit.jacoco-maven-plugin.version>0.8.3</orekit.jacoco-maven-plugin.version>
<orekit.maven-assembly-plugin.version>3.1.1</orekit.maven-assembly-plugin.version>
...
您可以使用http://search.maven.org/#search上的搜索功能找到插件的最新版本。属性名称都遵循orekit.some-plugin-name.version的模式，插件名称应在Web表单中使用以检查可用版本。
请注意，在某些情况下，由于不兼容性，无法使用最新版本。例如，当插件最近未更新并且与其依赖项的较新版本发生冲突时。
还要注意，某些插件使用可能需要更新的配置文件。这通常是maven-checkstyle-plugin和spotbugs-maven-plugin的情况。可能需要检查/checkstyle.xml和/spotbugs-exclude-filter.xml文件。
在提交这些更改之前，您必须检查一切是否正常运行。因此，请运行以下命令：
mvn clean
LANG=C mvn -Prelease site
如果出现问题，请通过更改插件配置或回滚到插件的早期版本来修复。
浏览生成的站点，从target/site/index.html页面开始，检查是否正确渲染。
当一切顺利且生成的站点正常时，您可以提交更改：
git add orekit/pom.xml orekit/checkstyle.xml orekit/spotbugs-exclude-filter.xml
git commit -m "Updated maven plugins versions."
完成文件 /src/changes/changes.xml 的最终版本。
在开发过程中，发布日期和描述通常只设置为 TBD，在这一步中，必须设置为适当的值。在这一步中，发布日期只是一个猜测，可能是未来一两周内，以便考虑到 5 天的发布投票延迟。
用描述发布的版本替换 TBD 描述：说明它是一个次要版本还是主要版本，列出该版本引入的主要功能等（参见以前版本的描述示例）。
提交 changes.xml 文件。
git add src/changes/changes.xml
git commit -m "为正式发布更新 changes.xml。"
必须更新多个文件以考虑新版本：
| 文件名 | 用途 | 需要更新 |
|---|---|---|
build.xml |
Ant 用户的构建文件 | 更新项目版本号。检查所有依赖项的版本与 pom.xml 一致。 |
src/site/markdown/index.md |
站点首页 | 更新关于最新可用版本的文本，包括来自 changes.xml 的重要更改。 |
org/orekit/overview.html |
API 文档 | 更新关于最新可用版本的文本，包括来自 changes.xml 的重要更改。 |
src/site/markdown/downloads.md.vm |
下载链接 | 声明新版本，不要忘记日期。 |
src/site/markdown/faq.md |
常见问题解答 | 在依赖项表中添加一行。 |
确保 ant 构建正常工作：ant clean clean-lib jar javadoc。
更新文件后，提交更改：
git add build.xml src/site/markdown/*.md
git commit -m "为发布更新文档。"
pom.xml 文件包含库的版本号。在开发过程中，该版本号的形式为 X.Y-SNAPSHOT。发布时，必须删除 -SNAPSHOT 部分。
提交更改：
git add pom.xml
git commit -m "为正式发布删除版本号中的 -SNAPSHOT。"
根据JDK版本（Oracle，OpenJDK等），可能会出现一些JavaDoc警告。通过运行以下命令确保没有JavaDoc警告：
mvn javadoc:javadoc
如果可能的话，使用不同的JDK版本运行上述命令。
使用以下命令在本地生成网站：
mvn clean
LANG=C mvn site
当工作合并到develop，release-*或master分支时，官方网站会自动更新。
当完成了所有前面的步骤后，本地git仓库保存了发布版本的源代码和构建文件的最终状态。必须给它打上标签并签名。请注意，在投票结束之前，标签只能用-RCx后缀进行签名，以表示发布候选版本。一旦投票成功，将在同一提交上放置没有-RCx后缀的最终标签（因此该提交将有两个标签）。使用以下命令进行标签和签名，将-RCn替换为发布候选版本号：
git tag X.Y-RCn -s -u 0802AB8C87B0B1AEC1C1C5871550FDBD6375C33B -m "版本X.Y的第n个发布候选版本。"
可以使用以下命令验证标签：
git tag -v X.Y-RCn
当标签准备好后，必须将分支和标签推送到Gitlab，以便每个人都可以进行审查：
git push --tags origin release-X.Y
良好的实践：等待CI在分支上成功后，发布release-X.Y分支到SonarQube，并检查一切是否正常
当设置完成后，通过运行以下命令生成构件：
mvn deploy -DskipStagingRepositoryClose=true -Prelease
在生成过程中，maven会触发gpg，要求用户输入访问签名密钥的密码。Maven没有提示我，所以我必须添加-Dgpg.passphrase=[密码]
命令执行完毕后，登录到SonaType OSS网站https://oss.sonatype.org/，检查暂存库中是否包含预期的构件及其关联的签名和校验和：
签名和校验和文件的名称类似，添加了扩展名.asc，.md5和.sha1。
有时，部署到SonaType OSS网站还会添加带有双扩展名.asc.md5和.asc.sha1的文件，实际上它们是签名文件的校验和文件，没有任何用途，可以删除。
删除orekit-X.Y.source-jar*，因为它们是orekit-X.Y-sources.jar*构件的重复项。（我们无法弄清楚如何让maven停止生成这些重复的构件）。然后点击“Close”按钮。
现在一切准备就绪，开发人员和PMC可以对发布进行投票。在论坛的Orekit开发类别中创建一个帖子，主题行的格式如下：
[VOTE] 发布 Orekit X.Y 版本候选 n
内容的格式如下：
这是为了发布 Orekit 库 X.Y 版本的投票。
X.Y 版本是一个维护版本。
X.Y 版本的亮点包括：
- 功能 1 描述
...
- 功能 n 描述
候选版本 n 可以在 GitLab 仓库的 release-X.Y 分支中找到，标签为 X.Y-RCn：
<https://gitlab.orekit.org/orekit/orekit/tree/X.Y-RCn>
发布说明可以在这里阅读：
<https://test.orekit.org/site-orekit-X.Y/changes-report.html>
Maven 构件可以在这里获取：
<https://oss.sonatype.org/content/repositories/orgorekit-xxxx/>.
投票将在 120 小时后进行统计，时间为 20yy-mm-ddThh:mm:00Z
（这是 UTC 时间）。
您还应该提醒PMC成员，让他们知道这次投票。根据项目治理，他们的投票对于发布是至关重要的。
如果投票失败，必须从OSS网站中删除Maven构件，删除存储库，并从Orekit网站的staging目录中删除非Maven构件。然后必须创建一个新的候选版本，具有新的编号、新的标签和新的构件。需要对这个新的候选版本进行另一次投票。因此，请进行必要的更改，然后从“标记和签署git存储库”步骤开始。
如果候选版本的投票成功，请按照以下步骤发布版本。
由于投票通过，必须为成功的候选版本添加最终签名的标签，并进行验证和推送：
git tag X.Y -s -u 0802AB8C87B0B1AEC1C1C5871550FDBD6375C33B -m "版本 X.Y."
git tag -v X.Y
git push --tags
将发布分支合并到master分支中，以包含所做的任何更改。
git checkout master
git merge --no-ff release-X.Y
然后提交并推送。
良好实践：再次等待CI成功，并在SonarQube上检查主分支报告是否正常。
将master分支合并到develop分支中，以包含所做的任何更改。
git checkout develop
git merge --no-ff master
然后更新版本号，为下一个开发周期做准备。编辑pom.xml文件的版本为SNAPSHOT，并在/src/changes/changes.xml文件中为新的更改腾出空间。
然后提交并推送。
良好实践：再次等待CI成功，并在SonarQube上检查开发分支报告是否正常。
必须使用OSS网站发布maven构件到发布库。在“Staging Repositories”中选择Orekit仓库，然后在Nexus Repository Manager中点击“Release”按钮。
导航到项目 > Orekit > Deployments > Releases，并确保X.Y版本的发布说明看起来不错。
为了增加项目的可见性，我们在Github上维护一个镜像。在Gitlab上创建的发布不会自动推送到这个镜像上，必须手动声明才能显示Orekit的活力。
Github会自动添加两个资产（标记源代码的zip和tarball存档）
在投票后，需要对Orekit网站进行几处编辑。
首先，克隆当前的代码：
git clone https://gitlab.orekit.org/orekit/website-2015
切换到develop分支。编辑overview.html：
overview.png图像。在_post/中创建一个新的发布文章，它将在News页面中显示（有关文章内容，请参见Announce Release部分）。
将修改推送到develop分支，等待Gitlab上的流水线完成，然后测试网站将会更新。
检查一切是否正常，然后将develop合并到master分支并推送修改。
当Gitlab的流水线完成后，官方网站将根据您的更改进行更新。
在Gitlab中，导航到项目 > Orekit > Issues > Milestones。点击对应于X.Y版本的行的“Close Milestone”。
最后一步是通过在论坛的Orekit公告类别中创建一篇帖子来宣布发布，主题行的格式如下：
Orekit X.Y 发布
内容的格式如下：
Orekit团队很高兴地宣布发布Orekit X.Y版本。
这是一个次要/主要版本，包括新功能和错误修复。
主要变化包括：
- 功能1描述
...
- 功能n描述
此版本依赖于Hipparchus X'.Y'
完整的发布说明请参见：
https://www.orekit.org/site-orekit-X.Y/changes-report.html
Maven构件可在Maven中央库中获取。
源代码和二进制文件可从Forge发布页面获取：
https://gitlab.orekit.org/orekit/orekit/-/releases
这里的主要区别是：
如果我们发布补丁版本X.Y.Z，则我们将使用存储库上已存在的release-X.Y分支来进行发布。
其中：
再次强调，补丁版本应仅包含不会破坏API的错误修复！
先决条件与次要/主要版本相同。
在这里，我们将在develop分支的基础上运行与次要/主要版本相同的检查，但是在release-X.Y分支上运行。
有关检查的详细信息，请参见上文（SonarQube：测试、代码覆盖率、代码质量 / Gitlab CI/CD：所有阶段都通过了）。
有人可能会认为release-X.Y分支应始终处于干净状态，因为它包含了最新的发布。
但是，为了修补目的，开发人员可能已经在release-X.Y分支上合并了bug修复。
在这里，我们将验证每个仍未关闭的合并请求（MR）的状态，这些合并请求在版本范围内。
从版本的里程碑开始，记录范围内未关闭的问题，并找到相关的合并请求。
然后，对于每个合并请求：
如果有问题，请先要求修复警告和错误！
补丁版本将在先前的发布分支上执行。
首先，检出专用分支：
git checkout release-X.Y
然后，在版本范围内合并所有合并请求（MR）到release-X.Y分支。
这里有两种情况，分别在下面的两个点中详细说明。
如果开发人员从release-X.Y分支开始进行更改，您可以简单地将MR分支合并到release-X.Y分支中。
请注意，如果在Gitlab中没有冲突，您可以直接从Gitlab进行合并；只需确保目标分支是release-X.Y而不是“develop”。
在存储库中找到MR，它应该在分支origin/merge-requests/XXX中，其中XXX是MR的编号
git merge --no-ff origin/merge-requests/XXX
--no-ff选项将强制生成合并提交，而不是在分支上进行快进合并。
您可以保留自动合并消息，除非您想要添加一些内容。
最后，解决任何冲突并提交结果。
如果开发人员从develop分支（或任何其他分支）开始，则MR分支可能包含不应添加到发布中的代码。
您将需要挑选适当的提交并将其添加到专用分支中。
建议使用IDE进行挑选，尽管下面的命令行将帮助您。
在存储库中找到MR和您感兴趣的提交。
在本地存储库中为该问题创建一个专用分支：
git checkout -b issue-YYY
其中YYY是MR XXX修复的问题的编号。
如果分支已经存在，请给它一个不同的名称，如integrate-issue-YYY或integrate-MR-XXX
列出您想要添加的提交的ID列表，例如A B C D（按提交的顺序）。
按照时间顺序挑选提交：
git cherry-pick A B C D
最后，解决任何冲突并提交结果。
返回到发布分支并合并issue-YYY分支：
git checkout release-X.Y
git merge --no-ff issue-YYY
对于补丁版本，请跳过此步骤。
与次要/主要版本相同。
与次要/主要版本相同。
pom.xml 文件包含库的版本号。
在 release-X.Y 分支上，版本号应为 X.Y 或 X.Y.Z（如果已经为此版本发布了补丁）。
将版本号从 X.Y 替换为 X.Y.1 或将 X.Y.Z 替换为 X.Y.Z+1
提交更改：
git add pom.xml
git commit -m "为补丁版本增加版本号。"
与次要/主要版本相同。
对于补丁版本，跳过此步骤。
根据 Orekit 治理规则，对于补丁版本，不需要 PMC 的投票。
与次要/主要版本相同。