This is done only once per major version (4.x, 5.x, 6.x, etc.) about 4-6 weeks before the planned official release of x.0. For minor versions, the work is done in current branch.
php doc/devtools/svnbranch.php branches/20.x
After that, you need to change a few details in lib/setup/twversion.class.php
, in both the New Branch and Trunk:
// Set the development branch. Valid are: // stable : Represents stable releases. // unstable : Represents candidate and test/development releases. // trunk : Represents next generation development version. $this->branch = 'unstable'; (...) $this->star = 'Tarazed'; // 'TBA' if not chosen
Commit the above changes with a message such as "REL Update $this->branch and Star Name"
$this->version = '21.0svn'; // needs to have no spaces for releases (...) // if already chosen, add chosen star in function tikiStars() 31 => 'Tarazed', // 20.x
Commit the above changes with a message such as "REL Change Trunk version to 21.0svn, added Star Name for 20.x"
More details on how to create a branch: SVNTips#Handling_branches
This star name is needed for the alpha because it is in the path: https://sourceforge.net/projects/tikiwiki/files/
lib/setup/wiki.php
, update $profilesLink
to the new branch
Note: The assets (img and css) supports up to 3 versions (trunk, 19.x and 18.x).
Update versions list (not appending more versions), example change to "trunk, 20.x and 18.x":
git@gitlab.com:tikiwiki/tiki-packages-build.git
VERSIONS: "trunk 20.x 18.x"
Update to add a new version, example change to include 20.x version, "trunk 20.x 19.x 18.x"
git@gitlab.com:tikiwiki/tiki-packages-build.git
"VERSIONS: "trunk 20.x 19.x 18.x"
resources/assets/css/styles.css
duplicate "VERSION 03" section to "VERSION 04" and change the colors.
resources/assets/img
duplicate down-03.svg to down-04.svg
Tiki Packages in GitLab: https://gitlab.com/tikiwiki/tiki-packages-build
Tiki Packages website: https://packages.tiki.org
As of 2018-10-11, we can't add 19.x because server is PHP 5.6: so this is on hold for now
templates/trackerinput/showtikiorg.tpl
and commit
usr/local/src/tiki
/usr/local/sbin/tim-common
BRANCHES="trunk 12.x 13.x"
/usr/local/sbin/tim-cron
Also...
If a new branch is created, then you need to manually update a few lines in the branch which is running for dev.t.o at the file:
./templates/trackerinput/showtikiorg.tpl
Search for "12.x", for instance, in that file, and add the corresponding hardcoded cases for the new branch.
Example:
Version: <select name="svntag"> <option selected="selected">trunk</option> <option>13.x</option> <option>12.x</option> </select> (...) <span class="buttonupdate{$field.fieldId}_{$item.itemId}" {if $field.version != 'trunk' && $field.version != '13.x' && $field.version != '12.x'}style="display: none;"{/if}>{button href="#showtikiorg{$field.fieldId}_{$item.itemId}{if isset($context.list_mode)}_view{/if}" _onclick="showtikiorg_process{$field.fieldId}_{$item.itemId}('update');" _text="{tr}SVN update{/tr}"}</span> (...) if (data.version == '12.x' || data.version == '13.x' || data.version == 'trunk') { (...)
See dogfood for general background info on this policy. The general principle is that most of *.tiki.org sites should be running supported versions before they are released while others will keep running with previous version (LTS).
Goals:
The various *.tiki.org sites collectively have a lot of users & data and cover quite a few features. Power users of these sites are usually quite familiar and can spot a bug or regression (something that stopped working) and report it efficiently.
Some sites are kept at the latest stable version (ex.: doc.tiki.org), while others are kept on the Long Term Support (LTS) versions (ex.: profiles.tiki.org). The list is maintained at Domains.
All sites are generally updated daily with minor revisions in each branch. So if a site is running 9.x LTS, it has the latest pre-released 9.x code. Exception: some legacy sites are kept for historical purposes in old unsupported versions, normally in read-only mode.
When a new major version is coming out, each of the sites identified as latest stable are progressively updated to the new version.
Start with the less critical one (ex.: themes.tiki.org)
This whole process typically takes 3-5 weeks because of discovery of new issues and the understandable delay to resolve them. Because of this incompressible time factor, it is important to start the dogfood process as soon as possible in the release process (as soon as all bugs are resolved on the pre-dogfood server)
Finding & fixing an issue while in pre-dogfood avoids wasted time and corrupted data on the real sites. Trying to save time by rushing a release just creates more work down the line.