Please wait

Structures

Page actions

Ongoing work

Communicate

All progress used to be relayed on live IRC channel: irc://irc.freenode.net/#tikiwiki but lately (Tiki 8 and up) Tiki dev-list is more used. Communication should be used at different levels; Specific team and all the community. It should be used to announce but also to implicate members and to get help (mainly for testing purposes).

Update relevant pages about progress, reports and regressions.

Coordinate with other teams

Review regularly the regressions and bugs with the wish list team

Check that a doc page for the version has been created

1.1. Preparatory work

Some steps here are not necessary if releasing only minor version but this is actually the most time-consuming part!

Create the release pages and component related to the new version

Using the content for the existing page from the previous version (copy/paste) create a set of page for the new version.

Tiki n (n being the version number)

Regressions in n.x (n being the version number)

Create a new item with the new version number in the category "Version" on dev.t.o

1.1.3.4. MyISAM

In tiki.sql (for your version), make sure all table creations are consistent. As of Tiki7, that means ending with ENGINE=MyISAM; (but it could change in the future). This is also required in the new schema updates.
Reference

1.1.5. Review all external links

For security, privacy, future-proofness, and site-deaths, the Tiki code should as seldom as possible link to outside of the control of the site admin or the Tiki community. A link to *.tiki.org/* with PluginRedirect is ideal.

quick script to check all http links in templates

grep -R http: templates | grep -v svn

Ideally, it would be done for the whole code base.

1.1.5.1. Make sure URLs are still active.

It's better to link to tiki.org/Something from which we can put a short page and a link, or even a Redirect

1.1.6. Check JSLint

1.1.7. Check PHP syntax is correct for each branch

Notably, 12.x has a minimum requirement of PHP 5.3 but after that 5.5 is used and some 5.5 required uses get backported to 12.x by mistake, especially the short array syntax (using [] instead of array() for instance).
Searching for these regular expressions on all *.php files, (but with the help of phpStorm's "context" in multi-file search set to "accept comments and string literals") seems to find them.

[, \(]\[(should find arrays declared using the short syntax - finds a few false positives in code with strangely positioned linefeeds)

(?:empty|isset)\([^\)\[]*-\>[^\)\[]*\((should find instances of "return value in write context" where a function is called inside an empty or isset test). Two found in vendor files, might need looking into for 12.5 release

1.1.8. .less files to .css conversion (optional)

If you know how to check this easily: Some contributors could have made changes to css or less files and forgot to change the other. A sync should be made, and any missing commits added to the branch. Compiling Less files with php console.php less:compile in the PhpStorm terminal produces results consistent among current developers.

This tool (or a version of it) might be able to decompile CSS into LESS which we could then compare somehow, but it wouldn't be trivial

1.1.9. Check the README file for manual commits

The "function update_readme_file" of doc/devtools/release.php will output to the top-level README:

Check if anyone has committed anything manually to README that needs to be brought back into this script

1.1.10. Remove any out of sync English strings

lang/en/language.php and lang/en/language.js may contain some tweaks to the English versions that were made after the string freeze. This is useful to improve the English text without breaking any translations. But this workaround should not be used forever and at each major release, this should be cleaned up. Strings should be removed from lang/en/language.php and incorporated in the relevant tpl and php files. Some judgment calls must be made to decide if the translation is invalidated or not. If you fix a typo in English, the translations are still good. However, if the meaning of the English string changes, the translations should be invalidated and translators need to review. This being said, if the meaning changes, it probably should not have been put in lang/en/language.php and lang/en/language.js in the first place.

For all the strings that are to be updated, once you replace in Tiki files (source and templates), you look up the language files which have a translation for the old string, and you make that translation the translation of the new string. Since they mean the same thing. Then you can delete the line in lang/en/language.php

1.1.11. Delete secdb files from previous versions

Ex.: When releasing 5.2, you may see db/tiki-secdb_5.1_mysql.sql lying around

1.1.12. Check that all PHP files have a feature check

Each PHP file in Tiki should start with a feature check. So if the feature is de-activated, the file is dead. If a particular file is discovered to be insecure, users can deactivate the feature until they upgrade to the release which contains a fix. To avoid forgetting to add this feature check on new files, a feature check script has been created. Some files, by design, can't have a feature check and these files should be audited manually.

1.1.13.1. Integrity

We are getting some files from Packagist, and they are not maintained by the official project. A check is required to make sure the files are the same. If the package is coming directly from the publisher, no need for an additional check.

1.1.13.2. Security

Are there any dependencies that have security releases? If so, the update is mandatory

1.1.13.3. General up-to-date-ness

Generally, a Tiki release should contain the latest stable version of the library. However, if there is a major update to a lib (which has a higher chance of breaking in the upgrade), it can be decided to hold back. If this is the case, indicate it below and specify the reason (and any relevant link to a discussion). If you feel it's too risky for the stable branch, then, choose instead to do in trunk, and there could be a backport later.

List of external libraries that we have decided to hold back on the upgrade.

Zend Framework 1

We are staying at ZF1 because it's a big job to upgrade, some components are not yet (or no longer?) available in ZF2, and thus, we will wait for now. NOTE that fix in r54095 is a workaround for a zf1 pbm fixed in zf2. It can be removed after replacement with zf2.

LTS policy

To be discussed: what is our policy for LTS versions? When do we stop updating the libs? (except for security releases)

1.1.14. Prevent directory browsing

Add index.php (see others for examples) to all directories in which it has been forgotten

Note while it is extremely important to prevent browsing in folders where there might be Tiki created content, like files, it is unclear if it provides any more benefit for folders that are open source code anyway, esp as I think we need route.php for tiki to work nowadays anyway. Hence we should consider revisiting this release task.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.