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
I m leaning towards option 3,Because most framework versions have this
semantics, it is better for users.
Huxing Zhang 于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 le
+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
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 , wrote:
> +1
>
> It seems like the beginning which is Jun's opinion, a
Hi,
I’d be careful of using the term RC (release candidate) as that has a
particular meaning at Apache. i.e a pre-release put up for vote by the PMC for
consideration of making it a release. Once released I’d not call it a release
candidate.
Thanks,
Justin
Hi,
On Wed, Jun 19, 2019 at 11:57 AM Justin Mclean wrote:
>
> Hi,
>
> I’d be careful of using the term RC (release candidate) as that has a
> particular meaning at Apache. i.e a pre-release put up for vote by the PMC
> for consideration of making it a release. Once released I’d not call it a
>
Hi,
> Yes, to avoid possible conflict, it can be changed to another term like
> alpha, beta, or milestone?
Sounds fine to me. To not do so might cause some confusion.
Thanks,
Justin
