在一次开发多个未来版本时，什么是良好的分支策略？

过去 我使用subversion作为scm开发了一个软件项目。到目前为止，开发总是发生在

trunk

，所以当需要修复bug修复时会出现问题。现在，我们想重新考虑我们的分支策略，其要求是：我们希望能够同时处理多个未来版本。 任务 这意味着：假设，我们正在处理的当前版本是1.0。下一个计划版本是2.0，之后的版本是3.0。现在我们已经发布了1.0版本 维护1.0版 开发2.0的功能 同时开发3.0的功能 当然，在其他两个版本中也需要在1.0中应用的修补程序。此外，2.0的功能也必须在3.0。此外，可能会计划一个次要版本，例如1.1，其中还包括新功能，并且必须单独维护。 可能的解决方案 我提出了以下分支策略： 行李箱将被废弃 对于每个新的计划发布，都会创建一个源自最后一个发布分支的分支 更改在版本时间轴中“向上”传播 让我再详细说明一下：在给定的示例中，我们将从trunk分支1.0版。此外，我们将从版本1.0分支2.0版，从2.0版分支3.0版。当在1.0中进行更改时，它将合并到2.0，然后合并到3.0。 这个问题 这是一种有效的方法吗？它会在技术上有效吗？是否存在组织缺陷？有最佳做法吗？ （所有互联网都会提出：“在主干中开发，在发布分支中维护”）。放弃后备箱对我来说特别奇怪 - 这是错的吗？