发布纪律衡量项目是否发布带版本号的发布版本——这是仓库中的工作真正到达用户的机制。下游使用者锁定版本、阅读变更日志、并在发布版本的边界上升级；一个从不切出发布版本的项目，迫使每个用户依赖无版本的快照。
- 类别：活力（类别内占 40%）
- 在总指数中的权重：8.8%
- 指标键名：
release_discipline
数值如何计算
| 组成部分 | 权重 | 判定标准 |
|---|---|---|
| 有发布版本 | 27 | 存在任何已发布的发布版本；条件与 v0.9.0 相同，折算为 27 分 |
| 发布时效 | 36 | 阈值与 v0.9.0 相同，折算为 36 分 |
| 发布节奏 | 27 | 阈值与 v0.9.0 相同，折算为 27 分 |
| OpenSSF Scorecard：Signed-Releases | 10 | Scorecard 的 0–10 结果，折算为 10 分 |
当发布数据不可获得时，该指标为 null——从活力中排除并重新归一化权重，绝不按零计入。当 Scorecard 不可用或报告为 n/a 时，Scorecard 组成部分同样被排除；该项检查仍完整保留其安全信号的地位。
为何将发布与提交分开衡量
提交活动与交付发布是两种不同的纪律。一个仓库可以在默认分支上持续涌动，而用户却要等上一年才能拿到包含修复的发布版本；相反的情形—— 分支平静、发布准时——同样存在。将开发活跃度 与发布纪律分开，使两种模式都清晰可见，而不是让一方掩盖另一方。
如何解读结果
- 发布时效是权重最高的组成部分。一个发布历史优秀、但十八个月前停止发布的项目，其读数会明显低于上个季度仍在发布的项目。
- 发布节奏奖励的是规律，而非频率本身。稳定的季度周期即可获得节奏分的大部分；最高档只是反映了活跃开发的类库中常见的短迭代周期。
- 数据来源是 GitHub 发布。只打版本标签而不发布 release、或仅通过注册表发布的项目，在此项的读数可能偏低；注册表发布时效在 软件包维护中单独衡量。
提升数值
- 通过仓库的发布机制发布 release，而不是仅打标签。
- 按可预期的节奏发布——小而规律的发布得分高于稀少的大型发布，且出于同样的原因更好地服务用户。
- 在任何休眠期之后，一次新的发布即可立即恢复发布时效组成部分。