I m leaning towards option 3,Because most framework versions have this semantics, it is better for users.
Huxing Zhang <[email protected]> 于2019年6月18日周二 上午9:44写道： > Hi All, > > I'd like to bring a discussion about the release versioning of Dubbo. > > The problem is the that the currently release versioning won't lead to > a stable state eventually. In each 2.7.x release, a lot of new > features were added, as well as bugfix, however, newly added features > will introduce additional bugs, which make 2.7.x not to be in a stable > state. > > The solution will be cut a branch that only contains bugfix, and do > not adding any new features. > This will cause us to consider what versioning scheme should be > considered for Dubbo. > > Option 1: use 4 digit versioning. > > For example, cut a branch called 2.7.2.x, that only contains bugfix, > next version should be 2.7.2.1, and 2.7.2.2, and so on. > New features are added to 2.7.3 or 2.7.4, and so on. > > Option 2: follow semantic versioning > > For example, 2.7.x only contains bugfix, next bugfix version should be > 2.7.3, 2.7.4, and so on, on some day the branch should be stable and > marked production ready. > New features are added to 2.8.x, to avoid possible conflict with > dubbox (they made serval releases to these versions), I suggest to > skip 2.8.x and go to 2.9.x. > > Option 3: new features go to 3.x > > Same to option 2, 2.7.x only contains bugfix, new features still go to 3.x > > I am leaning towards option 2 because it follow the semantic versioning > most. > I also did an investigation of other famous project like spring-boot, > kubernates, and grpc, they all follow semantic versioning. > > Regarding version ended with RC or Milestone, based on my > investigation above, in most cases, they only add RC or Milestone > suffix when there is at least a minor version upgrade (which means new > features are added). > > For example, in spring-boot, the version is: > > - 2.0.8.RELEASE > - 2.0.9.RELEASE > - 2.1.0.M1 > - 2.1.0.M2 > - ... > - 2.1.0.RC1 > - 2.1.0.RELEASE > - 2.1.1.RELEASE > > Normally there won't be a RC or Milestone for a bugfix release. > Kubernetes has its own release versioning specification as well [2]. > > So I suggest for newly added feature, if we think it is unstable, we > should release serveral RC or milestone first. e.g. in the 2.9.x > branch, do some relasese called 2.9.x-M1 or 2.9.x-RC1. > > What do you think? > > > [1] https://semver.org/ > [2] > https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning > -- > Best Regards！ > Huxing >
