Home
This wiki page shows our working process.
Please find Tutorial for CUBRID development. It presents our dev and QA process.
We are going to adopt Vincent Drissen Model with tweaks. Since we are going to work on GitHub, developers will fork the project and develop. Please refer the first figure of the page.
Differences from Vicent Drissen Model: The model proposes to finish release and hotfix branches when it releases. We will keep release and hotfix branches, since a patch for legacy versions may not be merged with develop branch.
A release branch will off from develop when ZAB(Zero Active Bug) is reached. We will keep fixing issues during ZRB(Zero Resolved Bug) and full tests. A developer can start to develop a new feature which will be shipped as the next version with develop branch.
The branching model assumes we will develop only one next version.
As the figure shows, we will keep the release branches to deliver patches in the future. We now have release/10.0 branch and will have release/10.1 when we are ready to ship it. The patches for a major and a minor version will be accumulated. For example, 10.0.1 would be a proper subset of 10.0.2.
When we deliver a hotfix for a released build, a hotfix branch will be off from the release branch with a particular release tag. Developers should apply a patch for both release(hotfix) branches and develop branch. Since we have to deliver patches and even hotfixes for legacy releases and they may not be successfully merged into master, we will not merge the fixes for patch versions into master branch. Developers should make a patch for both release(s) and develop branch. The patches may be different for some cases in which the current develop branch has evolved from the release branch and is different from each other. It is very important for developers to make it sure that there will not be a regression regarding a patch for legacies.
Hotfixes are rarely provided to a client who has a difficulty to upgrade up to the latest patch version. The hotfix branches are off from the release tag that the client uses and usually include a fix for a particular issue for the client.
Release tags for major and minor versions are on master branch, while those for patches and hotfixes are on their release branches.
You may use git flow which provides high level commands for Vincent Drissen Model for convenience.
We are using JIRA. Please visit JIRA to browse issues and report an issue.
There are two types of version in JIRA:
- Permanent Version: versions for major, minor and patch releases, e.g, banana pie(10.1), cherry
- Transient Version(subversion): versions for task branches, e.g, DWB_cherry
Transient versions are particular versions for long tasks. It will be kept until the task is merged into develop. The branch issues will be updated as its develop version and transient versions will be removed when the branch is merged. Naming convention for transient versions is to use develop version name as suffix, for example, DWB_cherry.
Patches will be accumulated in order to avoid any regression with an upgrade. One of our policies for patches is to supply up-to-date patch version of its release branch and guide users to upgrade their builds to it. For example, when one uses 10.0.1 and the latest patch version of 10.0 is 10.0.5, our first choice should be to ship 10.0.6 with the fix of the issue. When it is hard for the client, we have to deliver a hotfix as 10.0.1-<one>.
Hotfixes will be rarely provided to a particular client who has a difficulty to upgrade to the latest patch. The hotfix branches will be off when we decide to deliver a hotfix version to a client. There would be few number of hotfix branches (hopely none). Hotfix should be minimized. It should be our last choice when no other option is available.
We will discuss hotfix with a client, actually customer support. The most important fact would be difficulties of the client to upgrade to the latest patch version.
Developers submit a code review with a pull request.
Checkin Message would be
[CBRD-<issue-number>] description
Please notice that [CR] is not required any more.
When you issue a pull request with a title “[CBRD-]”, merge operation would be seamless since the title of a pull request would be the commit message.
The first line of “description” for a pull request should be a line of summarized message for release note. When we issue a commit message with quality, authoring release notes can be done without pain. “Description” can be spanned to multiple lines. However, the first line should be the summary. The detailed descriptions including problem statements, analysis, root cause, its impact, the fix, test impact, potential customer impact and so on can be followed with an empty line which separates them from the title line.
It is usual to commit many changes to issue and merge a PR. Individual commit messages are not required to follow the above rules and it is better to describe the change itself.
We are doing "Squash and Merge" to commit a change for an issue. Please refer to https://help.github.com/articles/merging-a-pull-request/ and find sections for "Squash your commits into one commit".
Dev should fix not only codes but also manuals and release note when one resolves an issue requires modification of documents. When it is not good to change the manual and/or release note together with codes, one should open an issue for documentation. Component/s for a document issue are “Manual” and “Document”. The examine necessity of document modification is one of the checkpoints of review process.
Communication via JIRA is highly required. Emails can be used as a supplementary way to let team to notice the issue and/or a comment link.