🔗 Squid 发布流程
🔗 发布类型
🔗 重大发布
适用于生产环境的缓存。代码更改有意保持最小化。当然，您仍可能在稳定版本中发现 bug。请检查您特定版本的 **待处理 Bug** 页面。
如果您在发布版本时遇到任何编译相关问题，请使用 bugzilla 报告，或发送邮件至我们的 squid-dev@lists.squid-cache.org 邮件列表。**不要** 向 squid-users 报告与代码相关的 bug。
🔗 小版本发布
适用于生产环境的缓存。
代码更改有意保持最小化。当然，您仍可能在任何版本中发现 bug。请检查您特定版本的 **待处理 Bug** 页面。
每个月第一个周末会发布新版本，**前提是** 自上次发布以来满足以下条件
- 至少修复了一个新的重大、关键或阻碍性 bug。
- 或，修复了 4 个或更多不太重要的 bug。
- 或，代码更改了 100 行或更多。
🔗 Beta 版本发布
这些版本适合进行升级规划等活动。命令行、cachemgr API 和 squid.conf 已冻结，预计在下一个主要版本发布之前不会发生变化。
每个月第一个周末会发布新版本，**前提是** Squid 版本处于 Beta 周期，并且自上次 Beta 版本发布以来已进行更改。
🔗 开发版本发布
我们不会为每次补丁都发布版本。取而代之的是，尝试每天自动进行快照发布。
快照发布是在运行构建测试之后进行的。打包的代码预计 **始终** 能干净地构建。如果您发现错误，请报告。我们的 BuildFarm 可以捕获许多问题，但仍缺少一些操作系统和编译器。
🔗 通用发布流程指南
Squid 开发人员以此流程为指导，决定如何以及何时发布新的 Squid 版本。
- 当用户可见的功能被认为可以正常工作时。
- 确定要包含的功能列表。
- 为代码创建特性分支。
- 此分支不再接受新功能。
- 应存在发布说明，
- ChangeLog 应反映所有已做的更改，无论大小。
- 发布 X.0.1 版本，并作为 **Beta** 版本宣布到 squid-announce。
- 在有重大进展时，根据 Beta 版本周期重复此过程。
- 当 X.0.Z 版本不存在 **重大** bug 时，
- 发布说明应完成。
- 给予最新的 X.0.Z 版本 10-14 天的 bug 倒计时。
- 如果发现重大 bug，返回到步骤 3。
- 如果出于任何原因进行了逻辑更改，则重新开始倒计时。
- 当之前的 X.0.Z 版本的 Beta 倒计时已完成时，
- 发布 X.1 版本，并作为 *稳定* 版本宣布到 squid-announce。
- 在有重大进展时，根据稳定版本周期重复此过程。
🔗 附加说明
- 不能正常工作的功能绝不应提交到主干。
- 所有回溯的更改都需要有相应的 bugzilla 报告或安全公告。