How to release

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

1. 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/5.x

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

2. 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).

3. Check database 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 4.0, upgrade to Tiki5.0
2. Checkout a fresh Tiki5.0
3. Export sql
4. Compare the two files and resolve any differences

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

4. Check JSLint

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

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. Test tarballs

Test on your server. Ideally, you have 1-2 other people trying on different servers.

7. Upload tarballs to Sourceforge

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 "3.0.rc1" ):

cd ~/tikipack/$VERSION
scp *bz2 *gz *zip $SF_LOGIN@frs.sourceforge.net:uploads

You need to have "release technician" status

Reference: http://apps.sourceforge.net/trac/sourceforge/wiki/Release%20files%20for%20download

8. Ask Communications Team to promote

• Communications Team Release

9. Update admin panel notifier

Ask Oliver Hertel to update http://tikiwiki.org/stable.version so Tiki installs are prompted to upgrade

10. Post package release

• Incrementing version number? Ex.: after 4.1 release, branches/4.x release number should be 4.2 (SVN) and trunk should be trunk or 5.0 SVN
  • There are hard-coded values in templates/tiki-admin-include-profiles.tpl
• _htaccess (should this be just after release or just before release?)

Release script

• 3.x
• trunk

Related notes

chat transcript of 3.0 RC1

Improve the release process

Reduce to one the number of places where Tiki version is maintained

Good: http://de.tikiwiki.org/xref-HEAD/nav.html?lib/setup/twversion.class.php.html Bad: http://de.tikiwiki.org/xref-HEAD/nav.html?db/convertscripts/tikiversion.php.html

script to test feature names

Manual check to make sure

1. No typos on using feature names
   • to avoid problems like the one solved on Commit #17972, Commit #21618, etc.
2. None are forgotten
   • Will all the work on Magic, AdminUIrevamp and Dynamic Preferences, chances are high to have lost some variables. Some features may have no way to set in admin panel. (ex.: make $lastup templates/tiki-bot_bar.tpl optional)

Ideally, the script would report on (knowing it won't be perfect):

1. To make a list of all possible feature_names used in the code
2. Make a list of all possible feature_names appearing in admin panels
3. Make a list of all possible feature_names appearing lib/setup/prefs.php

2010-04-14: new script: doc/devtools/lessermagicreport.php

script to check all links

external Make sure sites are still active.

grep -R http: templates | grep -v svn

to doc.tikiwiki.org

• There is a script to test all outgoing links from Tiki. All outgoing links to doc.tw.o can be copied to a wiki page and we can check for missing docs. This will help detect duplicates, etc. http://doc.tikiwiki.org/Restore+Help+Pages

Is there a way to also check for plugins and modules? etc.

2010-04-09: A new/better script for this is on the way

Script to check for internal broken links

• This would help us detect, and delete useless (and potentially unsafe) files.
• We already have a script which checks if php syntax is ok. What about broken links, like images?
  • also, as an example, tiki-register_site.php was removed as a link from the admin panel, presumably by accident.

Stats

• Would be good for marketing to report on how many commits by how many different people since the previous version. 3.2 vs 3.1 for minor. 3.0 vs 2.0 for major

Other ideas & script

• Check presence of index.php and .htaccess in all directories
  • Check for empty directories
• upload to SourceForge.net
• script to check/validate, then minify js & css (perhaps minify should be done by Tiki: )
• script to detect invisible weirdness in files
  • detect dos and do dos2unix?
  • http://svn.fckeditor.net/FCKeditor/trunk/_dev/php_bom_finder.php
• security script: list of plugins with no validation?
• Test run with http://profiles.tikiwiki.org/Test_All_Features to see if any features/plugins/modules are crashing Tiki
• Add MD5s
• php doc/devtools/release.php --testrun
• Report on % of completion of each translation
• Improve handling of Security Check exceptions
• Calculate translation % completeness on TikiWikiInternationalizationAndLanguages

To branch or not to branch

Historically, we branch several weeks/months before an official release. However, it would also be possible to agree on a freeze and branch much later. Please add your arguments and preferences below.

Benefits of branching early (ex.: 4-6 weeks before)

• Devs can still work on unfinished or new features
  • after all, not everyone may want to just fix, or would have to make himself familiar with unknown code first
• (Psychological) Signal that freeze is in effect (only disadvantage in case if we do the way as in past merging to trunk is that people need to SVN switch, see below Merge or not to merge)
• no accidental breaking code by devs not knowing of feature freeze (living in a bubble?)
• clear and better controllable border between trunk and feature-freezed code
  • try on trunk. working? backport to branch
    • new and unexperienced devs won’t have to fear of doing something really bad when working on trunk

Benefits of branching at release time, or as late as possible

• Less work of merging from branches/4 to trunk (in case we need to merge - see below)
  • and possibly the other way around
• (Forcibly) Route manpower to only fixing and improving present and presently working (freezed) features.

Discussions

To merge or not to merge

Benefits of backporting from trunk to branch

For example branch 4.x would be something like "pre-proposed" where quality team can decide to rollback if anything inappropriate gets in, but they don't need to approve each and backport themselves to stable 4.x yet. At time of 4.0 release, this branch will become stabilized (what 3.0 is now) and new proposed branch for 4.x will be created...

• avoids merge pain to trunk
• devs can decide what code they think works well tested in trunk and would like to see released and can backport themselves
• only tested things (bugfixes, UI enhancements) get in from trunk (no new features after feature freeze/branch creation) and we can be more sure we don't release weak / untested / unstable
• possibility to clean and KIL as needed in the branch 4.x before final release without loosing code people work on in trunk but don't make it in time (keeping things on track in trunk)
• we don't switch the merge/backport stream all the time before main release comes and don't force people to swicth to work on another branch

Benefits of merging from branch to trunk

• faster development and focus on release (when devs are forced to switch to 4.x branch)

• Release script
• Release