Hi, On Fri, Jun 14, 2019 at 1:02 PM Jason Joo <[email protected]> wrote: > > Hi, Huxing > > In my view generally one release is followed after Alpha, Beta, RC is a quite > normal workflow. And it keeps the stability, steady and seriousness to the > final release. Especially for common users they can not recognize where 2.7.3 > is a release for RC purpose in name "2.7.3" but things could be clear if name > it "2.7.3-RC1" or "2.7.3-BETA".
I think normally for project following the semantic versioning spec[1], where X.Y.Z means major version, minor version, and bugfix, it is rare for a bugfix version to have release candidate versions. The problem is that current versioning does not follow semantic versioning. There is too much new features added in 2.7.2, which caused the instability. My suggestion is to make sure 2.7.x only contains bugfix, so that the bugs will converge eventually. New features should be added by bumping minor version to 2.8.x or later. [1] https://semver.org/ > > Sure it's a personal opinion. > > best regards, > > Jason > > > On Jun 14, 2019, at 12:50, Huxing Zhang <[email protected]> wrote: > > > > Hi, > > > > On Fri, Jun 14, 2019 at 11:42 AM Jason Joo <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> Hi, Huxing > >> > >> Something you may misunderstand that the versions in descriptions from Jun > >> should like: > >> > >> 2.7.3-RC1 > >> 2.7.3-RC2 > >> 2.7.3-RC3 > >> 2.7.3 > > > > This naming looks weird to me. If 2.7.3-RC1 is not production ready, > > what does 2.7.2 mean? They are inconsistent. > > > > What I am proposing is: > > > > 2.7.3 (Not production ready) > > 2.7.4 (Not production ready) > > ... > > 2.7.N (mark as production ready) > > > > > > > >> > >> > >> best regards, > >> > >> Jason > >> > >>> On Jun 14, 2019, at 11:26, Huxing Zhang <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> Hi, > >>> > >>> On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <[email protected] > >>> <mailto:[email protected]> <mailto:[email protected] > >>> <mailto:[email protected]>>> wrote: > >>>> > >>>>> I am +1 on marking current release NOT production ready. > >>>> > >>>> Do you think several rounds of beta or RC is necessary before every > >>>> formal release? > >>> > >>> Given that 2.7.0-2.7.2 has already been published. I think it is weird > >>> that the next version is 2.7.3-RC1. > >>> Instead of that I think keep bumping the version to 2.7.3 is ok, as > >>> long as we let the community know that it is not production ready > >>> until the community formally announce it. > >>> > >>>> > >>>> Other people have different opinions? > >>>> > >>>> Jun > >>>> > >>>>> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <[email protected]> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <[email protected] > >>>>> <mailto:[email protected]>> wrote: > >>>>>> > >>>>>> Hi, All > >>>>>> > >>>>>> Recently, Jeff and I and some other volunteers from the community are > >>>>>> trying to improve the performance of Dubbo. When doing benchmark, we > >>>>>> found that the usage of CompletableFuture in the 2.7.2 has a > >>>>>> significant performance degradation (both QPS and RT) when running > >>>>>> under the JDK 1.8 version (but performs ok under JDK 11), check this > >>>>>> issue[1] for more details. Thinking of some other problems found > >>>>>> recently, the service registration discovery problem in 2.7.1[2], the > >>>>>> configuration model unification problem[3], etc. I think we need to > >>>>>> reconsider the evolution plan and stability guarantee of 2.7. > >>>>>> > >>>>>> From my point of view, version 2.7 is releasing in a relatively fast > >>>>>> pace, with each version containing lots of features and refactoring > >>>>>> changes, I think this is a good sign for the community. But this also > >>>>>> brings us new problems, especially when we don't have enough > >>>>>> infrastructures and time to test each version, it is very difficult to > >>>>>> ensure the functional stability and well performance of each version. > >>>>>> Considering our roadmap in the near future, this situation seems to be > >>>>>> even worse. According to our draft roadmap released in last meetup in > >>>>>> Beijing, we will release the native cloud service discovery model in > >>>>>> version 2.7.3 or 2.7.4, which is almost a complete refactoring of > >>>>>> Dubbo's current service discovery functionality, I doubt the both the > >>>>>> API and feature stability is hard to guarantee without several > >>>>>> releases. > >>>>>> > >>>>>> So my main concern is the stability of the 2.7.x version. Maybe the > >>>>>> released or the following several releases should be marked as > >>>>>> non-production available from the community level officially, or > >>>>>> consider add beta, RC, etc. tags to some version numbers if necessary. > >>>>>> What do others think? > >>>>>> > >>>>>> What do others think? > >>>>> > >>>>> I am +1 on marking current release NOT production ready. > >>>>> It is necessary for users to try out the new features and provide > >>>>> feedback, I think after several iterations, the 2.7.x will enter into > >>>>> stability eventually. > >>>>> > >>>>>> > >>>>>> 1. https://github.com/apache/dubbo/issues/4279 > >>>>>> <https://github.com/apache/dubbo/issues/4279> > >>>>>> 2. https://github.com/apache/dubbo/issues/4213 > >>>>>> <https://github.com/apache/dubbo/issues/4213> > >>>>>> 3. https://github.com/apache/dubbo-website/pull/388 > >>>>>> <https://github.com/apache/dubbo-website/pull/388> > >>>>>> > >>>>>> Jun > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Best Regards！ > >>>>> Huxing > >>>> > >>> > >>> > >>> -- > >>> Best Regards！ > >>> Huxing > >> > > > > > > -- > > Best Regards！ > > Huxing > -- Best Regards！ Huxing
