I am leaning towards option 2. I think it is inevitable to add new features to the 2.x version before the 3.x release. Use option 3 after the 3.x version is released.
Best Regards! On Jun 18, 2019, 11:55 AM +0800, Jason Joo <[email protected]>, wrote: > +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 <[email protected]> wrote: > > > > 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 > > > > >
