Versions¶
New feature development and stability improvement are equally important to product. But adding new features will affect stability, dubbo uses the following version development pattern to achieve a good balance.
Two versions evolving at the same time¶
- BugFix Version:low version,e.g.
2.4.x
. This is called the GA version, which can be applied in production. We are supposed only to fix bugs in this version, and increase the third version number when release. - Feature Version:high version, e.g.
2.5.x
. We add new features to this version, so applications have opportunities try new features.
When features in 2.5.x
are proved stable enough, we will announce 2.5.x
as a beta release.
When 2.5.x
proved stable after enough test on enough applications:
2.5.x
, the GA Version, only do BugFix, the main version to be used. We can try to promote applications to upgrade to GA at the desired time.2.4.x
, no longer maintained. When bugs appear, applications have no choice but upgrade to the latest stable version- Sunset Clause- We create a new branch
2.6.0
based on2.5.x
for new features.
Pros¶
- GA Version are promised stable:
- only BugFix
- GA Version got enough tests before promotion
- New features can respond quickly in Feature Version and allow applications to try that
- Significantly reduces development and maintenance costs
The responsibilities of users¶
Users should always keep in track with the GA Version, make sure all bugs were fixed.
There is a fake proposition: regular upgrades bring more risks. Here's the reasons:
- GA remains stable after a trial period.
- Bugs find on GA will be fixed immediately.
- Comparing with the on-need-upgrade (only upgrade when find a serious problem, and may span multiple versions), upgrade periodically can flat risk. Experienced a long cycle of large projects, students will have such an experience, the tripartite library version does not upgrade for a long time, the result of the problem had to upgrade to the new version (across multiple versions) a huge risk.