How to release

Table of contents

• Requirements
• Procedure
  • 1. Create a branch, if you are releasing a major version
  • 2. Checkout Tiki
  • 3. Run script
  • 4. Test tarballs
  • 5. Upload tarballs to Sourceforge
  • 6. Ask Communications Team to promote
  • 7. Post package release
  • Release script
  • Related notes
• Improve the release process
  • Reduce to one the number of places where Tiki version is maintained
  • Check database structure
  • script to test feature names
  • script to check all links
  • Script to check for internal broken links
  • Stats
  • Other ideas & script
• To branch or not to branch
  • Benefits of branching early (ex.: 4-6 weeks before)
  • Benefits of branching at release time, or as late as possible
• Discussions
  • To merge or not to merge
    • Benefits of backporting from trunk to branch
    • Benefits of merging from branch to trunk

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)

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

4. Test tarballs

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

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

6. Ask Communications Team to promote

• Communications Team Release

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

Check database structure

Does a fresh install with tiki.sql have the same structure as an upgraded Tiki (we used to have a script for this, but hasn't been ported to new database structure.

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

script to check all links

external
Make sure sites are still active.

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.

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

Accept	Undecided	Reject
3	0	0
Kissaki luci marclaporte

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.

Accept	Undecided	Reject
1	2	2
jonnybradley	luci Kissaki	sylvieg marclaporte

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

Accept	Undecided	Reject
2	0	0
luci sylvieg_if_we_have_the_ressource

Benefits of merging from branch to trunk

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

Accept	Undecided	Reject
1	0	1
sylvieg_if_we_do_not_have_the_ressource		luci

---