How to release Preparation

Ongoing work

Communicate

All progress should be relayed on chat channel: https://gitter.im/tiki-org/community and/or Dev Mailing List. 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), for example Tiki29
• Regressions in n.x (n being the version number), for example Regressions-in-29.x
• Create a new item (sub-category) with the new version number like this for 29.x in the category "Tiki Version" on dev.t.o

Create a clear roadmap and schedule milestones.

Notice:

1. Don't forget to adapt and improve.
2. Add the new version on this page in the section "About Development"
3. Update https://tiki.org/All+Releases (you can add the Star chosen name later)

1.1.1. Start consultation process for star name

Each major version has a star name (aka codename). This should be picked before releasing the alpha.

1.1.2. Fix major bugs and regressions

• current
• Do some tests thanks to the Pre-Dogfood Server

1.1.2.1. Acknowledgements

• Ask bug submitters (including security vulnerability reporters) how they would like to be credited in the Tiki release announcement.

1.1.3. Check SEFURLs

Make sure _htaccess and web_config are in sync.
For more info, go to the Clean URLs or ask Arildb.

See also: https://sourceforge.net/p/tikiwiki/code/HEAD/log/?path=/trunk/web_config (instructions at the top of the file)

1.1.3.1. Make sure URLs are still active.

NOTE: From tiki30 please use the the script introduced in https://gitlab.com/tikiwiki/tiki/-/merge_requests/9389 to inspect the codebase
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.3.2. No direct calling of JavaScript

• Remove any link to JavaScript files via http like this one, which are not controlled by the site admin. Here is an example of the fix: http://sourceforge.net/p/tikiwiki/code/34348

If there is no way to store than JavaScript on a reputable CDN, this is OK, but it should be optional, default to off. And it should be using https!

1.1.4. Check the README file for manual commits

Note: For Tiki 30 and later, this step can be skipped. The README is no longer generated per release; the version from master (trunk) is shared across versions.

• 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.5. 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.
  • Here is an example: https://sourceforge.net/p/tikiwiki/code/50704
  • Related: Mass spelling correction

grep -v '^//' lang/en/language.php

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.

Note: Do not change the following English strings since they help to specify the context (indicated by _C):

"Off_C(on-off)" => "Off", "Start_C(imperative)" => "Start", "Finish_C(imperative)" => "Finish"

1.1.6. Check that all PHP files have a feature check

Note: For Tiki 30 and later, this step can be skipped. It is now part of the CI.
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.

Run https://gitlab.com/tikiwiki/tiki/-/blob/master/doc/devtools/securitycheck.php and check each "potentially unsafe" file.

1.1.7. Check external software library dependencies

This applies to all External Libraries coming from Composer :
https://gitlab.com/tikiwiki/tiki/-/blob/master/vendor_bundled/composer.json

We need to find a balance here. For stability, we can use notation to get minor updates with no backward compatible changes. However, this means that we must manually review to update libs to latest stable version (which have new features, and possible backward compatibility issues). Background reading: Why your software project will slowly die without continuous updating.

Some dependencies are known to need a Cleanup, and perhaps there are still some elsewhere in the code which haven't yet been moved to Composer.

1.1.7.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.7.2. Security

• Are there any dependencies that have security releases? If so, the update is mandatory
  • https://security.sensiolabs.org

1.1.7.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.

1.1.7.4. Stability check across branches

Run the script doc/devtools/check_composer_stability.php to compare stability of Composer packages across Tiki branches.

This script ensures that:

• No newer version of Tiki uses an older or less stable version of a Composer package than an older release.
• Older versions of Tiki do not use less stable components than more recent branches.
• All version constraints follow a logical upgrade path (e.g., `~1.2` → `~1.3`, or `^2.0` → `^3.0`).
• Any library newly added in a higher branch is still accounted for in the comparison logic.

The job runs automatically on scheduled pipelines, but can also be triggered manually via the GitLab CI/CD interface when needed.

Report any inconsistencies in:

• Dependency version downgrades
• Packages added with lower stability than earlier branches
• Unexpected version constraints

  
  

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

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.8. 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.

find . -not -path \*\.svn\* -not -path \*vendor\* -type d -exec ls {}/index.php \; | grep "No such file"

Since Tiki 27.x, this is handled in composer post-install commands by https://gitlab.com/tikiwiki/tiki/-/merge_requests/4409/diffs#a952570108511b7817893c82bea3341a7afe5adf

1.1.9. Prefs

1.1.9.1. Generate preference report

As per Preferences report to make sure this still runs and see if there any obvious issues. And attach the file to the version page (ex.: doc.tiki.org/Tiki12)

1.1.10. Security patches

In coordination with the Security Team.

This step should be done just before the actual packaging, to avoid disclosing a vulnerability. In some cases, this will be done after the alpha and beta stages.