-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Main development branch. All development is accumulated into this branch.
Upstream branch on which trunk is based. Updated when upstream commits are merged to trunk.
General fixes compatible with upstream should be merged into this branch from where upstream developers can easily pick them.
All minor features not related to time-related SQL (f.ex. new option to a script) should be merged into this branch where they are left to upstream developer's consideration to accept or reject.
Adjustments that should be reverted back on upstream merge. F.ex. disabled tests.
Each release, i.e the version publicly used should have its own branch to go through the stabilizing process (accumulate bug fixes, new features are generally prohibited). Release branches are named like this:
natsys/1.0
natsys/2.0
Bugfix releases are fixated inside release branches as tags with minor version counter (e.g. 1.1, 1.2, 2.1).
Any developer can have his own personal fork where he can create as many branches as he wants. He can then issue pull requests to merge his branch into trunk. Commits that break the integrity of the product (produce compilation or runtime errors) should go to the private branch as a part of some development task. Upon the task completion before merging branch into trunk these conditions must be met:
- branch is compilable;
- main test suite completes without errors.
Before merging the task into trunk multiple commits should be united into single commit (see git merge --squash). This single commit can be put into another local branch from where pull request will be issued.
Before merging the task into trunk the author may consider asking for code review from another developer. Though, this is not obligatory and is left to the author's sole discretion, it is good manners to do so if changes are done to another's code.
All global functions or common class methods as well as global variables or common class data members that are used exclusively for system versioning begin with prefix vers_. Exception is done for names that contain explicit notion of system versioning, f.ex.: versioned().
Don't tell what you did (f.ex. with verbs 'made', 'coded', 'created', etc.), tell what is in commit. Be specific (f.ex. 'disable warning' tell what warning). If commit is related to a task, commit message should duplicate task name (in some shorter way if task name is long). Segmentation fault, assertion failures are shortened to appropriate signal names (like in kill -l): SIGSEGV, SIGABRT. If C++ exception name is known, it should be used instead.
Commit message must start with capital letter and must not end with period. For multi-line messages leave second line blank.
PREFICES: Message [task refs]
SQL: SIGSEGV in push_warning() [fixes #99]
For modifications on SQL layer.
For modifications on InnoDB layer.
When modification is done on scripts only. Configuration files also fall to this category.
When modification is done on style only (formatting, renaming, etc.).
When modification is done on tests only.
Fixes after upstream merge.
Any miscellaneous prefix that will help to identify commit topic quickly.
git tag base-V natsys/base
git co -b natsys/V natsys/trunk
git push -u origin natsys/V
3. create release info here
git tag -a natsys/V
Fill message with modified info:
- heading # characters removed;
- very long info text is shortened.
Info examples may be viewed with command:
git tag -n30
When developing a new feature contribute tests for that feature too. But put feature and tests in different commits. So, PR should consist of two patches.
All code committed to trunk should conform to MySQL General Development Guidelines.