The development of TQUIC follows git-flow branching model and adheres to Semantic Versioning.
The development of TQUIC follows git-flow, but makes some minor differences for GitHub.
For the official repository, developers should follow git-flow .
masterbranch is the stable branch. Latest commit of the
masterbranch is unit-tested and regression-tested.
developbranch is the development branch. Every commit of the
developbranch is unit-tested, but not regression-tested.
release/vX.Y.Zbranch is the temporary branch created for release. The code on this branch is undergoing regression testing.
For the forked repository, developers don't need to strictly abide by the git-flow. Each branch of the forked repository is equivalent to a feature branch. Specific Suggestions are as follows:
developbranches of the forked repository with that of the official repository.
developbranch of the forked repository.
After completion of
featurebranch development, developers submit Pull Request to the official repository for code review.
During the review process, developers may continue to modify and submit code in their feature branches.
In addition, the
bugfixbranch is also maintained in the developer's forked repository. Different from the feature branch, developers should submit Pull Request from the
release/vX.Y.Zbranches of the official repository respectively.
Follow the following procedures to release a new version:
Create a new branch from the
developbranch with the name
release/vX.Y.Z. For example,
Tag the version of the new branch with
X.Y.Z-rcN(N is patch number). The first tag is
0.10.0-rc1, the second tag is
0.10.0-rc2, and so on.
For the submission of this version, do the following:
Modify version information in cargo.toml file.
Test the functional correctness of the version. If it fails, fix all the bugs in the
release/vX.Y.Zbranch, and return to the second step with patch number added by 1.
Complete the writing of Release Note.
release/vX.Y.Zbranch into the
masterbranch, and delete the
masterbranches into the
Tag the latest commit of the
Once a release branch has been created, it is generally not allowed to merge
release/vX.Y.Z from the
develop branch. This ensures that the
release/vX.Y.Z branch is frozen, making it easy for QA to test.
release/vX.Y.Z branch exists, merge the
bugfix branch into the
release/vX.Y.Z branches at the same time, if there are bugfix behaviors.