+1 It seems like the beginning which is Jun's opinion, and for addition optimizing the version naming strategy.
Users won't care about whether we go with 2.7.1, 2.7.2 or 2.7.x, 2.8.x, 2.9.x, 2.10.x so i think both of them are fine for me. Just pick one and go on. best regards, Jason > On Jun 18, 2019, at 11:45, Shunyu Lei <shunyuma...@gmail.com> wrote: > > I m leaning towards option 3,Because most framework versions have this > semantics, it is better for users. > > Huxing Zhang <hux...@apache.org> 于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 >>
