[Suggest] Standardize branch definitions to ensure that no BC is generated

[ymh199478]

提议

被提案为了明确提交的分支，以避免产生BC (Break Change)问题。我们建议：

版本控制方案

Kratos 和其第一方包遵循，semver语义化版本，次要和补丁版本永远不发生 BC。

如何提交

• 所有的 bug 修复，都应当提交到最新稳定分支(例如：2.0 分支)， 除非 bug 修复，修复了下一个主要版本的问题，否则永远不应提交到 main 分支
• 完全向下兼容的次要特性，应当被提交到最新稳定分支
• 主要新特性或是发生了 BC 的变更，应当被提交到 main 分支

备注

• 次要特性：在已有功能的基础上添加实现或是增加完全向下兼容的接口
• 主要新特性：全新的特性

补充

对于 kratos，已经发布 2.0 stable 版本，建议切出 2.0 分支，以应对后续向下兼容的次要特性开发和 bug 修复，而 main 始终留给主要新特性的开发和不向下兼容的提交。默认情况下，用户显示的是 2.0 分支，而非 main。

Reference

• https://golang.org/doc/modules/version-numbers
• https://semver.org

[pokitpeng]

看起来不错，但是不兼容的特性为什么不放到feature分支呢？

[ymh199478]

@pokitpeng feature 前缀的分支通常被保留用作具体的新特性开发，将它是做下一个版主要版本的分支不符合惯例用法，同样从语义层面，我们很难知道它到底是兼容性的特性还是非兼容性的，换句话来说，到底是 2.1 的新特性还是 3.0 的新特性？

使用具体的版本号（如：2.0）作为 默认(deault) 的稳定分支，以及使用 main 作为下一个主要版本，在语义上表达会更加自然。

通常情况用户更加倾向于稳定的版本，明确的版本分支，会明确的告知用户它是稳定的。

[shenqidebaozi]

是否同时应该建议用户使用指定版本的包，而不是 latest。

[shenqidebaozi]

@Terry-Mao @tonybase @longXboy @Windfarer PTAL