Discuss: how to develop new feature in separated branch

There are three purposes for developing new features in a separate branch:

  1. Guarantee the quality of the master branch
    The quality of our master branch is always poor, which to a certain extent also leads to the poor quality of each new version we release. In issues, we can often see that there are many bugs related to non-GA features. I think this is not appropriate.
    New features, fully tested in a separate branch, and then merged into the master branch. In the most ideal case, our master branch can be released at any time.

  2. Improve development efficiency
    To develop a new feature, a lot of time is spent fixing bugs. Develop in a separate branch can test faster and fix bugs faster.
    For example, some functions have been developed, and corresponding tests (not simple unit-tests, but more systematic tests) are also ready. The original logic needs to be reviewed first, and then tested after merging, which requires a long time to wait.
    In the development of a separate branch, we can quickly merge the code for testing, while reviewing the code. In addition, it is much more convenient to fix bugs in a separate branch. Depending on sufficient test cases, we can fix bugs in batches and add test cases.

  3. Flexible delivery
    We are now using the train-catching model, which requires us to get on the train atomically. After the development in the separate branch, the test is completed, the conflict resolution is completed, and the review is completed, up to this step, there are no changes to the master branch. In that case, the time to get on the train will be quick.
    If you develop on the master, but find that the sprint cannot be completed/tested, then you can only add switch/experimental features.

At present, there are several main concerns:

  1. Trouble with conflict resolution
    There are already methods in this area, you can merge the refactored code into the master first, and then develop based on the refactored part.

  2. Feature compatibility issues
    The owner of this feature needs to consider the compatibility issues carefully when planning the feature, including when designing and testing.

In general, I think the advantages of developing features in a separate branch outweigh the disadvantages, and it is also a key way to truly improve the quality of TiDB. I used this method in the development of CTE before, although it is not the best practice, but I can feel its benefits. If you want to try this development method, I can do my best to help you.

1 Like

Hi @wjhuang2016 thanks for your sharing! It is a good example of best practices developing a feature, as we ever discussed.

I moved this topic to general category as you can see its usage, meta category is for the forum itself, I’ll try to find a better name to distinguish.

Besides, this topic is more like a best practice sharing than a proposal to be adopted in the community. As it is a proposal, do you want it to be formally documented in our development guide?

No, this development style is at the very early stage and isn’t accepted by everyone.
I want more and more people to try it and overcome its disadvantages.
Maybe proposal isn’t a good name for this topic.