The goal is to make the feature as generic as possible so it may be used in various contexts. Also, we must be sure it doesn't duplicate another existing feature.
A very important decision is where to commit? Stable-LTS, Stable, Dev (trunk), Mods or experimental? You may want to checkout the RoadMap and Version lifecycle.
See also: Freeze and Slush
Quick overview intended to help know where to commit to right now in most situations. See Branches section below for more detailed explanations.
Commit status and order for each open branch:
I want to commit to: | What is allowed: | Commit first to: | Afterwards commit to: |
---|---|---|---|
11+ | open | - Bug fixes: 10x, do not commit to trunk - Enhancements: trunk |
Security fixes: 9x & 6x |
10x+ | partial freeze (brief slush, freeze coming) |
10x | - Will be semi-auto merged to trunk - Backport to 9x if needed |
9x | only 9.2 release blockers | 10x | Security fixes also to: 6x |
6x | security fixes only | 10x & 9x | NA |
Root: https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/
Name | BRANCH | Current number | Comments |
Next (10) | branches/10.x | 10.0 | Bug and regression fixes, and feature enhancements with little risk of regression are OK. Is currently being semi-auto merged to trunk so all fixes here will also appear in 11+ (but watch the svn list if you can to check your fixes are merged correctly) |
Stable LTS | branches/9.x | 9.2 | Bug and regression fixes, and minor feature enhancements with little risk of regression are OK but must now (since 9.2 beta 1) be back-ported from 10.x. Later in the cycle, these commits also become reviewed by the Quality Team. |
Dev | trunk | will become 10.0 | Most development (new features) happens here. New features, need to be functional, but don't need to be complete. In theory, should be releasable at any time. This is the place for refactoring. Cosmetic code changes should be done here after the Semi-automatic merging period has ended. Also: Update language stringsIf you must change the English version (but are not changing the meaning and so the translations are still valid, please use mass spelling correction. If you can't use that, just add to pending text corrections.. If you commit to trunk, and after you want to commit to a stable branch, please see how to merge a commit from trunk. |
Old stable LTS | branches/6.x | 6.7 | Only security fixes and commits that will be reviewed by the Quality Team. See the Quality Team page more details on the procedure. Translations are OK as well. Commits to LTS must have been developed and tested previously on higher branches (at least trunk) unless they do not apply there (for example, a fix to a feature that was removed later). See here for more info. |
Mods | mods in trunk | n/a | If your feature is too specific or too experimental for the main branch, it can go into mods. Please read: To Mods Or Not To Mods. There are no branches for mods. |
Experimental branches | many | n/a | All developments for things that are not stable enough yet or just intended as proof of concept before the real work starts. These branches will never become a released branch directly, the author of the experimental branch must move the functionality in the Dev branch when it's ready. |
1.9.x, 2.x, 3.xLTS, 4.x, 5.x, 7.x and 8.x
There are no more planned releases of these versions. If you are running one and commit a fix , please merge manually your fix to the appropriate branch.
Lines: 16-19 | Lines: 16-20 | ||
{BOX(title="Snapshot" align="center")} | {BOX(title="Snapshot" align="center")} | ||
* __Automatic merging?__: ''Yes, commits to 10x ((Semi-automatic merging period|semi-auto merged to trunk))'' | * __Automatic merging?__: ''Yes, commits to 10x ((Semi-automatic merging period|semi-auto merged to trunk))'' | ||
+ | ** ''Avoid code-styling, documentation or other non-functional changes to trunk during this period'' | ||
* __Upcoming releases__: | * __Upcoming releases__: | ||
** ''9.2 beta is out for testing'' | ** ''9.2 beta is out for testing'' |