• HowToRelease
HowToRelease

软件包 (Packages)#

有关已创建软件包及其内容的概述，请参见 下载 (Downloads)。

发布步骤 (Release steps)#

下面列出了发布新版本需要按顺序执行的步骤。所有没有自己工单 (ticket) 的必要提交都可以引用 #563。所有步骤都假设你正在使用 bash（无论是原生的 Linux、macOS，还是在 WSL 或 git bash（或其他 mingw bash）中）。 此外，你应该准备好密码，或者更好的是在所有相关远程服务器上部署 ssh 密钥。

合并阶段 (Merge phase)#

对 SUMO 主干 (trunk) 的重大更改应在发布日期前约两周结束。这尤其指将项目分支合并到主干。此时通知依赖软件（Veins、VSimRTI、flow 等）的开发者也是一个好主意。 - 向 sumo-dev 发送邮件，通知即将发布的版本，以便“贡献” (contributed) 的作者可以检查他们的代码是否兼容。

冻结阶段 (Freeze phase) (发布日 - 7)#

  • 检查源代码
    • 编译，尝试消除警告并提交补丁
    • 运行 tools/build_config/checkStyle.py 并提交更改的文件
    • 检查日历以更新版权声明
    • 检查是否需要 增加 TraCI 版本 并在 python 中重建 TraCI 常量 (tools/traci/rebuildConstants.py)
    • 检查是否需要增加网络版本，并更新 NWFrame::MAJOR_VERSION 中的值。之后需要更新 netconvert 测试。
    • 更新作者信息
  • 检查常规测试
    • 特别注意作为示例的测试，见 tests/examples.txt!
    • Win64 和 gcc4_64 不应有失败的测试，其他平台的重要性较低
    • 如果有失败的测试，且未标记为已知错误 (known bugs)，请在仔细检查后保存它们，或打开一个工单并分配一个已知错误。
    • 如果由于 netconvert 更改而有必要，请重新检查/重建测试网络
    • 运行 tools/devel/orphaned_tests.py tests 检查孤立测试，并修补测试套件以将它们重新添加回去
    • 再次检查测试
  • 检查文档
    • 更新 变更日志 (ChangeLog)
    • 使用 tools/build_config/rebuildConfigDocsAndXsd.py 生成选项文档和配置文件的 xsd 模式
  • 更新 tools/build_config/templates.py 以包含自上次发布以来添加或兼容性已修复的任何工具
  • 检查内部测试（同上），特别是（将要）发布的场景
  • GitHub
    • 如有必要，添加新的 里程碑 (milestone)
    • 检查所有剩余的工单，并将它们分配给以后的里程碑或分配给人员。
  • 场景（可选）
    • 如果旧版本无法在当前版本上运行，或者对场景进行了重大更改，请为发布准备场景
  • 运行 git submodule update --remote 更新子模块，并在必要时提交更改

现在主干已冻结。所有不引用即将发布的版本的开放工单的提交都必须在单独的分支上进行。冻结阶段不应超过一周。目标是修复所有场景并修复所有未分配给以后里程碑的失败测试。

发布日 - 1 (Release day - 1)#

所有场景此时都应已修复。

> git tag -a v0_13_7 -m "tagging release 0.13.7, refs #563"
> git push --tags

发布日 (Release day)#

夜间构建 (nightly build) 应该已经生成了所有可发布的软件包。如果没有，则推迟发布。（完整的文档、测试和源代码发行版可以通过 "make dist" 构建。） 以下内容需要在 S:\daily 目录中：

如果一切正常：

  • 在 S:\Releases 中创建一个新文件夹
  • 创建新的 sumo.dlr.de-release
    • 将文件夹从 S:\Releases 复制到 releases 目录 scp -r /s/Releases/1.25.0 delphi@ts-sim-front-ba.intra.dlr.de:docs/releases
  • 更新 eclipse.dev/sumo 网站
    • 在 config.yaml 的 Default Parameters 部分修改版本号 (Version) 和 DOI 号 (DOI)
  • 创建新的 sourceforge-release
    • 在 Web 浏览器上登录，在 https://sourceforge.net/projects/sumo/files/sumo/version%201.25.0/ 创建新文件夹并上传文件
      • 由于文件大小，可能需要分几轮进行
    • 通过单击每个文件后的带圆圈的 "i" 更改默认下载属性
      • Windows 的默认值是 sumo-win64extra-1.25.0.msi，macOS 是 sumo-1.25.0.pkg，其他所有平台是 sumo-src-1.25.0.tar.gz
  • 完成 Zenodo 版本草稿，上传 sumo-src-1.25.0.tar.gz，添加发布信息（也可以稍后完成）并发布它
  • 在 https://projects.eclipse.org/projects/automotive.sumo 创建一个新的 Eclipse 发布（登录后应有一个 "Create Release" 按钮）
  • 在 elib 中创建一个新条目
  • 更新 opensuse build service 上的文件
  • 更新 ubuntu ppa（参见 https://askubuntu.com/questions/642632/how-to-bump-the-version-of-a-package-available-in-another-users-ppa）
    • 这假设你已安装 devscripts 包以及所有 sumo 依赖项
    • 解压特殊的源代码发布 tar xzf sumo_1.25.0.orig.tar.gz
    • 运行 cd sumo-1.25.0 && tools/build_config/ubuntu_release.sh 并输入发布评论
    • 使用 dput -f ppa:sumo/stable ../sumo_1.25.0*_source.changes 进行上传
  • 针对 winget 发起拉取请求 (pull request)
  • 使用 twine upload /s/daily/wheels/*1.25.0*.whl 将 wheels 上传到 PyPI
  • 场景（可选）
  • 通知用户新版本
  • 关闭 里程碑 （目前需要手动重新定位开放工单）
  • 将最新版本添加到 Wikidata 中的 "software version identifier" 语句（这将更新有关 SUMO 的维基百科文章），确保选择最新版本作为 "preferred rank"，并将前一个版本设置为 "normal rank"。

发布后清理 (After-release cleanup)#

现在主干已重新开放以进行更改。

  • 等待自动的 flatpak 拉取请求出现并构建，然后接受它
  • 在 src/config.h.cmake 中重新启用 HAVE_VERSION_H
  • 在 CMakeLists.txt 中将版本重命名为 "git"
  • 在 变更日志 (ChangeLog) 顶部插入一个新的空 "Git Main" 部分
  • 提交更改
  • 喝你最喜欢的饮料和/或吃蛋糕