======================== Suricata 向后移植指南 ========================

本文档描述了如何将内容向后移植到当前稳定版Suricata发行版的过程。大多数情况下，这涉及安全修复和/或错误修复；但在某些情况下，新功能也可能被移植到旧版Suricata中。

任何时候都存在多个Suricata版本：

  • 主分支（Master）

  • 主要稳定版

  • 旧稳定版

例如当前基于以下分支的3个发行版：

  • master: 8.0.0-dev，当前开发分支

  • main-7.0.x：主要稳定版（注意我们正在调整命名规范）

  • master-6.0.x：旧稳定版

关于Suricata的发布节奏和*生命周期终止*政策，请参阅 https://suricata.io/our-story/eol-policy/。

后续章节将讨论何时进行移植、移植内容以及相关准则。

应该移植哪些内容？

通常团队创建工单时，我们会添加*Needs backport*相关标签，必要的移植任务会自动生成。如果您处理的工单没有此类标签或关联的移植任务，则可能无需移植。若您认为该问题需要移植，请在工单或相关PR中告知我们。但有时我们可能会遗漏这些。

决定移植内容的基本原则：

选择概述

所有待移植项都应评估以下方面：

  • 风险预估：改动是否会引入新缺陷？需考虑变更范围和影响项

  • 行为变更：移植对系统行为的改变程度。例如解码新增封装协议的小改动可能导致更多流量进入Suricata

  • 默认设置：若问题改变行为，能否设为可选？实现成本如何？

创建移植工单——新问题

Redmine：针对安全和错误修复，创建新Redmine工单时需标记"Needs backport to x.0"标签，其中x.0是受支持的Suricata版本（如7.0.x）。

创建移植工单——现有问题/PR

我们力求减少"遗漏移植"（即应移植但未移植的工作）。这种情况常发生在无Redmine工单或工单未标记移植需求时。

因此我们将定期审查：

  • 未标记移植的Redmine工单（包括近期关闭的），确定哪些需要添加标签

  • 无关联Redmine工单的PR。需要移植的应标记*needs backport*

随后定期为上述识别项创建移植工单。此时会评估适用的目标版本。某些针对master或当前版本的报告可能不适用于旧版。

Git移植工作流

若您处理的任务需要移植，请仅在master分支的PR合并后开始移植流程。步骤如下：

  • 确认需移植的提交：从合并到master的PR开始，仅选择该问题相关的提交

  • 将每个提交逐一移植到新分支：从最旧的提交开始。使用``git cherry-pick -x commit-hash``（其中``commit-hash``是master或main-7.0x中待移植提交的哈希值），这会保留与原始提交的关联

  • 解决冲突：某些移植提交可能包含合并冲突。若冲突较小，直接在移植提交中修正

  • *添加额外提交*（如需要）：例如调整移植代码以适应旧版行为

创建PR：

请在标题注明这是移植PR（例如*(7.0.x-backport)*），并添加相关里程碑标签。

在PR描述中注明关联的移植工单。

质量保证 --

必要时添加suricata-verify的PR。某些现有suricata-verify测试可能需要调整版本规范。