How to release

This is the overall the responsibility of the Release coordinator coordinates the various Release Roles.

Requirements

1. Linux shell environment, that you connect to via SSH
2. Subversion 1.3 or more
3. PHP 5.x CLI with MySQL, iconv, DOM and SimpleXML extensions
4. PHP configuration must allow running external programs (like shell scripts)
5. Plenty of disk space and memory ;) - at least 64M of memory for php (in php.ini for php-cli)

Procedure

All progress should be be relayed on live irc channel: irc://irc.freenode.net/#tikiwiki

1. Preparatory work

This is actually the most time-consuming part!

1.1. Fix major bugs and regressions

• Regressions in 8x
• Regressions in 9x
• Tiki9
• Do some tests thanks to the Pre-Dogfood Server

1.2. Mods

1.2.1. Check mods version

Check lib/mods/modslib.php and trunk/tiki-mods.php to make sure they are at this version.

1.2.2. Test a mods

Test one of the themes and coordinate with Gary for any issue

1.3. Check database

1.3.1. Check _tiki.sql suffixes

• As explained in Database Schema Upgrade, all .sql files in installer/schema should finish with _tiki.sql (otherwise, they are considered as local .sql patches)
  • This is a common mistake. A test on quality.tiki.org or in release script would be nice for this, and thus catch them early.

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

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

1.3.3. Drop Table

In tiki.sql, 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"

1.3.4. MyISAM

In tiki.sql, take sure all table creations are consistent. As of Tiki7, that means ending with ENGINE=MyISAM; (but it could change in the future)
Reference

1.4. Make sure CDN version is in sync with code

The jQuery CDN links are in tiki-setup.php and these should correspond with the version numbers in lib/jquery/jquery.js and lib/jquery/jquery-ui/ui/jquery-ui.js (which should also be noted in jquery-tiki-readme.txt)

• example

1.5. Check SEFURLs

Make sure _htaccess and web_config are in sync.
For more info go the documentation

1.6. Review all external links

For security, privacy and future-proofness, The Tiki code should as seldom as possible link to outside of the control of the site admin.

grep -R http: templates | grep -v svn

1.6.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.6.2. No direct calling of JavaScript

Except for reputable CDNs, remove any link to javascript files via http like this one, which are not controlled by the site admin.

1.7. Check JSLint

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

1.8. 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.9. Remove any out of sync English strings

• lang/en/language.php may contain some tweaks to the English versions that were made after the string freeze.
• There should be removed from lang/en/language.php and incorporated in the tpl and php files
  • mass spelling correction

1.10. Delete secdb files from previous versions

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

1.11. Check security

Run doc/devtools/securitycheck.php and check each "potentially unsafe" file.

2. Create a branch, if you are releasing a major version

This is done only once per major version (4.x, 5.x, 6.x, etc.). For minor versions, the work is done in current branch.

php doc/devtools/svnbranch.php branches/7.x

More details on how to create a branch: SVNTips#Handling_branches

2.1. Post-branching operations

2.1.1. Update $profilesLink

In lib/setup/wiki.php, update $profilesLink to the new branch

2.1.2. Make new profiles

• Contact Pascal St-Jean and Greg Wheat to ask them to make new profiles.

2.1.3. dev.tiki.org

• Add the branch as an option for the Tiki Version field in the Bugs & Wish list tracker
• Update Daily Build
• Update Get code

Tiki 9 branch process

Robert Plummer, Jean-Marc and jonny B had a BBB session running on live.t.o to talk through the branching process on 29th March 2012 - the recording is available here in case it's any use to anyone in the future.

3. Checkout Tiki

You need to get a subversion checkout to a new directory (of this branch)

Make sure you don't have any spaces in the path to this new checkout (as of Tiki 5.x).

4. Update twversion.class.php before the release

Look for section with "Release Managers should update this array before release." of twversion.class.php (of your relevant branch)

• increment the version number in the constructor
• update list of valid releases in tikiVersions()
  • Make sure you add all Tiki versions (not just the one you are doing now). Ex.: when 5.0 is released, 4.2 will probably exist, as this was added to branches/4.x but not merged by script.
  • change the version branch to "unstable", "stable", or "trunk" as explained in that file
• Commit your changes with this commit message (change \$VERSION by the version of the release):

[REL] Preparing \$VERSION release

5. Run script

Go to the newly created directory

php doc/devtools/release.php --help

php doc/devtools/release.php --howto

Follow instructions of the HOWTO, which will explain which how to use the release script. The release script has an interactive mode, enabled by default, that will ask you if you really want to do each step. It also ask for a confirmation before commiting any changes, so you can have a look at them with another shell by using this command:

svn --ignore-externals status
svn --ignore-externals diff

6. Check the generated README file

• Check links/content in the generated README file

7. Create and test pre-release packages

• This is done by executing the script with the release version as argument, using the format major.minor.sub
• Use the --help option of the release script for advanced help on options (like using a web proxy)

php doc/devtools/release.php 7.0 preRC4

8. Launch the release script

After testing, launch the release script and follow the answer 'y' to every steps (This will make automated tests, update README / copyrights / changelog / languages files, tag the release, build the release "tarballs" ... )

php doc/devtools/release.php 7.0 RC4

9. Test the produced "tarballs" and share the testing

Test on your server. Ideally, you have 1-2 other people trying on different servers. In case of a major version (x.0), you need at least 3 installations from 3 different people

10. Upload tarballs to Sourceforge

When the "tarballs" are tested, follow the steps to upload on SourceForge: http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download

To upload the 'tarballs', copy-paste and execute the following line (and change '$SF_LOGIN' by your SF.net login and $VERSION with the version, which may look like "7.0.rc1" ):

cd ~/tikipack/$VERSION
scp *bz2 *gz *zip $SF_LOGIN@frs.sourceforge.net:/home/frs/project/t/ti/tikiwiki/$RELEASEFOLDER$

You need to have "release technician" status on SourceForge. Ask an Admin if you don't have it.

11. Announce the good news on devel mailing-list

And ask the Communications Team to launch the announce-spreading process as described on Communications Team Release

12. Admin panel update notifier

• Update notifier

13. Update lib/setup/twversion.class.php after the release

• change $this->version = '8.3'; to 'SVN pre 8.4';

Related links

• Release Roles
• When to release - think popcorn
• chat transcript of 3.0 RC1
• How to improve the release process
• Freeze and Slush
• Translation branching strategy
• When to Branch

• Release script
• Release