Commit messages may start with one or more (max. 5) of the tags listed at the top of changelog.txt to distinguish changes. See also Guidelines for intro page for each release.
Current tags table
| Tag | Description |
| [BP] | Indicates a back-ported code from higher version (branch) of some sort (usually cherry-picks) |
| [DB] | For any changes in the database |
| [DOC] | For improvements in the tips or contextual documentation provided to the user/admin/developers |
| [ENH] | A enhancement does not really add any feature, but makes things work better (e.g. look and feel, performance...) |
| [FIX] | For bug fixes of any sort |
| [KIL] | For removals of unused or obsolete files. |
| [MOD] | It is a change which may be disruptive. For example, changing the default value of an option. |
| [MRG] | For branch merges, generally performed by the merge scripts |
| [NEW] | For commits adding a new feature on Tiki |
| [REF] | For refactoring; changes the structure of the code (to make it cleaner or clearer), without changing its actual behaviour. |
| [REL] | For the release process |
| [REM] | For feature removals |
| [SEC] | For security fix operations. If you feel you have reason to put this tag, please first contact security at tiki.org. |
| [TRA] | For translation |
| [UI] | For specific user interface (UI) improvements, referring to particular details of interactivity, look, and feel of the page elements and overall page |
| [UPD] | For updates of third party/vendor libraries |
| [UX] | For user experience improvements (more general than UI improvements) that make Tiki easier to understand and use (more details in https://dev.tiki.org/UX ) |
Formatting
The format should be in the form of min 1 and max 5 commit tags defined above + exactly one space + optional name of the feature immediately followed by colon and exactly one space + description of the changes. Only the commit messages containing the tags will be considered for the release changelog.txt. For small commits like typo fixes, you do not need to provide the commit tags at all as it does not make sense to have them mentioned in the changelog.
Valid Commit Message Format Examples:
- [FIX][UI][UX] Comments: fix the indentation of the replies
- typo fixed
Invalid Format Examples:
- [Fix][UI,UX] Comments : fix the indentation of the replies
- [UI][UX]Comments:fix the indentation of the replies
Dealing With Reverts
When you need to revert some commit manually (e.g., it was a part of more complex Merge Requests with squashed commits where reverting the whole MR is undesired) just make a new commit where you copy-paste the original commit message and prepend it with "Revert ".
Example:
Revert [FIX][UI] Comments: fix the indentation of the replies
You can also use "Revert: " followed by the original message in double quotes (the Gitlab default):
Revert: "[FIX][UI] Comments: fix the indentation of the replies"
Commits RegExp Pattern
To avoid pushing commits with missing or invalid tags or information you can include the following pattern to your Tiki fork's Repository Settings Push rules (Settings > Repository > Push rules):
^(Revert:? \"?)?((\[(BP|DB|DOC|ENH|FIX|KIL|MOD|MRG|NEW|REF|REL|REM|SEC|TRA|UI|UPD|UX)\]){1,5} +[^\[\]: ]+( +[^\[\]: ]+)*(:( +[^\[\]: ]+)+)?|[^\[\]: ]+( +[^\[\]: ]+)*(:( +[^\[\]: ]+)+)?)\"?$
Since this MR (on master branch) we have integrated Husky to check if your commit messages formatting is correct. It will not let you commit the changes if your message is not nicely formatted.
Deprecated tags
SVN used to be used as Tiki code primary reference. Not any more.
| [bp/rXXXX] | Backport revision XXXX to current branch. Intended for committing a change already made in trunk to an earlier version. A backport reference should be added in front. For example, [bp/r61102][FIX] ... in a commit message to the branch branches/16x, means this fix is a backport of trunk revision 61102 to the next version of Tiki 16x. Depending on the period, backports are subject to an extra level of review so please read Quality Team and Where to commit first or ask on the dev mailing list or community chatroom if unsure. |
| [rb/rXXXXX] | Revert changes made by revision XXXXX. For example, adding [rb/r61102] ... in a commit message to the branch branches/16x, means the change committed in revision 61102 are rolled back (removed, reverted) to the previous state, before r61102. |