Loading...
 

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!

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

Create a clear roadmap and schedule milestones.


Notice:

  1. Don't forget to adapt and improve.
  2. Add the new version page in the "About Development" menu
  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. This should be picked before releasing the alpha.

1.1.2. Fix major bugs and regressions

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 database

Note: all database check steps, from Tiki 18, are done automatically by the release script by checking the last CI run for that branch. https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/release.php

Which itself uses
https://gitlab.com/tikiwiki/tiki/-/blob/master/.gitlab-ci.yml

1.1.3.1. Check _tiki.sql suffixes

1.1.3.2. Structure

Does a fresh install with tiki.sql have the same structure as an upgraded Tiki from the previous version?

  1. Checkout a fresh Tiki 6.0, upgrade to Tiki 7.0
  2. Checkout a fresh Tiki 7.0
  3. Export SQL (ex.: mysqldump)
  4. Compare the two files and resolve any differences


Use the new script

Related:
http://www.maatkit.org/doc/mk-table-sync.html

1.1.3.3. Drop Table

In tiki.sql (for your version), make sure all table creation starts with
DROP TABLE IF EXISTS
This avoids that when people re-install, they get an error "table already exists"

You can use the following command line to scan tiki.sql:

Copy to clipboard
perl -le 'while (<>) { $line++; $drop=1 if /^DROP/; die("DROP missing at line $line") if /^CREATE TABLE/ &&!$drop; $drop = 0 unless /^DROP/; }' db/tiki.sql


@Ricardo and @Roberto: Please test new script https://sourceforge.net/p/tikiwiki/code/65638 and add to release script

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

@Ricardo and @Roberto: Please review https://sourceforge.net/p/tikiwiki/code/65625/ and incorporate to release script

1.1.3.5. InnoDB

The InnoDB installation depends on the table definition having ENGINE=MyISAM added to it (because a text conversion is done by the installer). Also check that the script tiki_convert_myisam_to_innodb.sql (for your version) includes all the new tables.
Like this: https://sourceforge.net/p/tikiwiki/code/43274/

1.1.4. Check SEFURLs

Make sure _htaccess and web_config are in sync.
For more info, go 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)

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
Copy to clipboard
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.5.2. No direct calling of JavaScript

1.1.6. Check JSLint

inside Eclipse/Apatana: http://www.jslint.com/

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. compile themes to css (from .scss or .less files) (optional)

  • Tiki19+: php console.php scss:compile
  • 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 (Tiki13-18) 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.
Copy to clipboard
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

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.

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

Script must be improved

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

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.
Copy to clipboard
find . -not -path \*\.svn\* -not -path \*vendor\* -type d -exec ls {}/index.php \; | grep "No such file"

1.1.15. Prefs

1.1.15.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.16. 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.

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.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Federated Timesheets
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools