领先一步
VMware 提供培训和认证，以加速您的进步。
了解更多Spring Framework 从 Jira 迁移到 GitHub Issues
Spring Framework 已将其所有问题历史记录从 Jira 迁移到 GitHub。这篇博文的目的是为您提供有关此迁移的背景和详细信息。
迁移详情
Spring Framework 所有 15 多年的问题历史记录（包括所有评论）都已导入到 GitHub。此类迁移需要考虑许多因素，因此让我们一起浏览并了解一些详细信息。
链接
如果您有指向现有问题的链接，例如 https://jira.spring.io/browse/SPR-16751，您将被重定向到相应的 GitHub 问题。如果您确实想要转到 Jira 问题，请附加查询参数 redirect=false。在 GitHub 端，导入的问题会链接回其 Jira 问题来源。
文本中出现的 Jira 问题键（例如“SPR-16751”）已替换为 GitHub 问题引用，这使得可以在双方的问题时间线上插入链接。另一个好处是在您将鼠标悬停在链接上时会显示迷你预览。
文本中出现的其他 Spring 项目的 Jira 问题键（例如“DATAJPA-813”）已替换为链接。例如，请参阅 #18558 中指向 Spring Data JPA 的链接、#20904 中指向 Spring Data MongoDB 的链接，以及 #16906 中指向 Spring Integration Extensions 的链接。
文本中出现的其他 GitHub 项目问题和拉取请求的链接将自动获得好处。迁移后，引用的问题时间线上将有链接指向 Spring Framework，并且在将鼠标悬停在链接上时会显示预览。例如，请参阅 #21362 中指向 Spring Boot 的链接、#20849 中指向 JUnit 的链接，以及 #20256 中指向 Jackson 的链接。
指向 GitHub 上任何项目的提交和源代码的链接也将自动获得好处。例如，请参阅问题 #18463 中指向源代码范围的链接。
Jira 详情
每个导入的问题都会在其描述的下半部分显示来自 Jira 的信息。这样做的目的是使来自 Jira 的所有信息都可以在 GitHub 上获得，而无需在两者之间来回切换。在可用时，您可能会看到以下一项或多项
- 受影响的版本
- 参考 URL
- 附件
- 子任务和相关问题
- 拉取请求和提交引用
- 回传版本
- 投票和观察者计数
请注意，投票和观察订阅无法迁移到 GitHub。即使 spring-issuemaster 拥有完全权限，它也只能投票一次。因此，请访问 GitHub 问题并重新应用反应并订阅以接收特定问题的更新。
标签
一些 Jira 字段已转换为 GitHub 问题标签
| Jira 字段 | 标签 |
|---|---|
| 问题类型 | "type: *" |
| 状态 | "status: *" |
| 解决方案 | "status: *" |
| 组件 | "in: *" |
还向导入的问题应用了两个额外的标签
| 标签 | 描述 |
|---|---|
"has: votes-jira" |
具有 10 多个投票的导入问题 |
"has: backports" |
具有回传版本的版本 |
我们利用这次机会简化了 Jira 字段值，例如，Jira 中的 25 个组件值对应于 GitHub 上的 5 个 "in: *" 标签。"status: *" 和 "type: *" 标签也经过了额外的整理和修改。
我们选择的标签与 Spring Boot 中使用的标签保持一致。Boot 团队对他们的流程和标签进行了认真思考，我们知道这种一致性会受到许多人的欢迎。请参阅完整的 标签集。
在 Jira 中，许多字段和标签都是可修改的。在 GitHub 中，只有贡献者才能添加或删除标签。这是非常有意义的。报告者只需描述问题，而贡献者则对其进行分类。开发人员和贡献者都可以使用标签进行搜索。
修复版本
一个 Jira 问题可以有多个修复版本，而一个 GitHub 问题只能有一个目标里程碑。这感觉像是缺点，但表面上看到的并非全部，并且此约束迫使我们考虑一些有意义的调整。
例如，请参阅 SPR-17226，其修复版本为“4.3.19”、“5.0.9”和“5.1 RC3”。虽然该问题已在这三个版本中修复，但无需污染“5.1 RC3”的发布说明，因为该版本当时仍在开发中。我们可以改为说它在 5.0.9 中修复并在 4.3.19 中回传，并且贡献者需要确保该修复传播到仍在开发中的下一个版本。这就是它在 GitHub 问题 #21759 上显示的方式。我们过去是否可以进行此调整？当然可以，但是 Jira 中对多个修复版本的支持并没有迫使我们考虑这一点。
这是一个小的调整，将导致更清晰的发布说明，但它也将影响我们提交修复的方式。当下一个版本在 master 上开发时，我们将首先将修复应用于当前生产分支，然后向前合并到 master，然后从旧的生产分支中挑选樱桃。而不是将修复应用于 master，然后从生产分支中挑选樱桃。结果是更清晰的提交历史，因为向前合并有助于 git 了解相关更改。
至于回传，由于一个问题只能有一个目标里程碑，因此我们必须创建单独的问题来表示修复的回传。要使用相同的示例，选择“5.0.9”作为目标里程碑是有意义的，因为我们只需要一个回传问题。如果我们选择“5.1 RC3”，则需要两个回传问题。为了让您了解这带来的巨大差异，假设 Spring Framework 从第一天起就在 GitHub Issues 上。如果我们使用后一种方法，今天我们将拥有大约 2500 个回传问题。如果我们使用前者，我们将拥有大约 1000 个。
对于历史回传，我们为每个版本创建了一个问题持有者。大约有 45 个此类问题。展望未来，我们将为所有回传修复创建单独的问题，这些问题将自动创建，主要用于版本跟踪。至于讨论，大多数对话应该发生在主要问题上，而回传问题仅用于与回传相关的讨论。
标记
毫无疑问，标记是迁移过程中最大且最痛苦的部分。15 年的问题跟踪历史反映了编程风格的巨大变化，这些变化反过来又决定了评论中显示的内容。
例如，一开始在评论中粘贴了大量的 XML，而 Markdown 将其视为 HTML 块，导致标签根本不显示。当然，如果这些标签用 {code:xml}...{code} 包围，则看起来会很好，但在当时，标记并不常用，并且 XML 代码段无论如何都会显示出来，没有强制执行问题，因此无法正确迁移。
还有很多其他复杂之处，例如转义花括号以避免单空格的影响，或者转义星号以防止它们作为粗体标记消失。我就不详细说明了。总而言之，我们付出了很多努力来确保标记转换的质量相当高。
需要特别强调的一个问题是在纯文本中（即代码块之外）使用“@”。这些是 GitHub 上的用户提及，会触发通知。您可能会惊讶地发现@Bean、@Configuration、@Component 都是实际的 GitHub 用户。像 @andy、@arjen、@brian 这样的名字引用在某些时候也经常与 GitHub 用户名冲突，所有这些在导入 17K+ 问题及其评论时都非常令人头疼。这就是我们小心转义它们的原因。以后，在创建新问题或评论时，请做一个合格的 GitHub 用户，使用反引号，例如 `@Foo`（是的，https://github.com/foo确实存在）。
背景
我长期以来一直使用并喜欢 Jira。迁移到 GitHub Issues 的想法并没有立即出现在我脑海中。相比之下，它看起来过于基础。让我彻底改变想法的原因与逐项功能的比较关系不大，尽管我必须承认自从迁移以来，GitHub Issues 确实让我印象深刻。我暗示的是更大的力量在起作用。
GitHub 几乎是每个开源项目的所在地，包括每个 Spring 项目，并且可以合理地预期所有用户都拥有 GitHub 凭据。因此，今天要求开发人员为他们依赖的或想要报告问题的每个开源项目的错误跟踪器维护单独的登录名已变得不可持续。
然后是将源代码和问题放在一起的好处。我之前已经提到了很多这样的好处，例如在一个项目中以及在 GitHub 上的所有项目之间，跨问题、拉取请求、源代码和提交的自动链接的引用。能够提及和通知任何 GitHub 用户。所有这些都是非常强大的好处，仅仅使用孤立的错误跟踪是无法实现的。我怀疑是否有人想回到开源项目托管在不同地方的日子。错误跟踪也是如此。
将源代码和问题放在一起还有更深层、不那么明显的好处。GitHub 将问题和拉取请求视为平等的。它们从同一个序列中分配编号。它们看起来一样（描述、评论、标签和目标里程碑）。它们在发布说明中没有区别地显示。拉取请求只不过是一个附加了提交的问题。
在 Spring Framework 的历史上，我们一直坚持要求每个拉取请求都必须有一个 Jira 问题。我们也不喜欢这种负担，但我们需要一个记录所有问题的地方。由于这种分裂的状况，拉取请求中应该讨论什么以及 Jira 问题中应该包含多少内容从来都不太清楚。
未来这不再是问题。我们期望问题或拉取请求，而不是两者兼而有之。如果您需要首先开始讨论，我们确实鼓励这样做，创建一个问题，然后，如果您提交拉取请求，PR 将取代该问题。两者仍然相关，并且没有任何丢失。对话只是跟随操作。
不容忽视的是标记问题。我毫不怀疑 Wiki 标记对于代码相关的讨论来说是痛苦的。我已经每天使用它很多年了。我已经习惯了，但是有些事情确实很难，并且需要付出太多努力。以下是一个提醒，说明在代码片段中显示像花括号和星号这样常见的内容需要做些什么：{{/endpoint/\{server-id\}/\{session-id\}/\{transport/\*\}}}。
毫无疑问，Markdown 对于代码相关的评论来说更容易。它需要更少的输入，并且在格式化代码时可以正常工作，因为它更简单，并且不会与代码中常用的符号发生冲突。从一开始，这一点对我来说就很明显，因为我多年来也并行使用过 GitHub 和 Markdown。我从来不明白为什么 Jira 仍然不支持 Markdown。需要明确的是，这不是决定性因素。这只是生活中必须忍受的事情之一，后来可以成为改变的额外动力。
最后但并非最不重要的是，如今大多数开发人员通过 Spring Boot 使用 Spring，Spring Boot 一直使用 GitHub Issues。仅从这一点来看，Spring Framework 就有足够的动力进行迁移，因为 Spring Boot 不会迁移到 Jira，而这将是为 Spring 用户创建更一致体验的唯一其他方法。
实际迁移
尽管做了很多准备，但没有什么比实际迁移的那一天更令人印象深刻了。我们使用了 GitHub 的非官方导入 API，该 API 文档中说明不会触发任何通知。在测试期间，我们没有注意到任何问题。一旦实际迁移开始，每个问题和每个评论的通知就开始涌入。
我们开始使用所有可用渠道联系 GitHub 支持。幸运的是，他们也注意到了。他们怎么可能不注意到呢？据我估计，在我们暂停之前导入的 2600 个问题一定产生了数千万封电子邮件，这毫不奇怪地导致了通知中断。
一天后，在 GitHub 支持人员纠正了问题并关闭了 Spring Framework 项目的所有通知以确保安全后，我们走上了导入所有问题的更平坦的道路，整个过程花费了 8-9 个小时。又花了几个小时对所有问题和评论进行了第二次处理，将 Jira 问题密钥替换为 GitHub 引用号，然后又花了几天时间检查和清理标记转换问题。
所有这些现在都已完成，我很高兴地宣布我们现在在GitHub Issues上开展业务。