How to release
Table of contents
Requirements
- Linux shell environment, that you connect to via SSH
- Subversion 1.3 or more
- PHP 5.x CLI with MySQL, iconv, DOM and SimpleXML extensions
- PHP configuration must allow running external programs (like shell scripts)
- 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.From a trunk checkout
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 directoryDisplay Basic Help
php doc/devtools/release.php --help
Display Release HOWTO, that details the whole procedure
php doc/devtools/release.php --howto
Follow instructions of the HOWTO, which will explain which how to use the release script
Check changes made by the release script before validating commits
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
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
Related notes
chat transcript of 3.0 RC1Improve 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.htmlBad: 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- No typos on using feature names
- to avoid problems like the one solved on Commit #17972, Commit #21618, etc.
- 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):
- To make a list of all possible feature_names used in the code
- Make a list of all possible feature_names appearing in admin panels
- Make a list of all possible feature_names appearing lib/setup/prefs.php
script to check all links
externalMake 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
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
- try on trunk. working? backport to branch
| Accept | Undecided | Reject |
|---|---|---|
| 3 | 0 | 0 |
|
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 |
|
|
|
After thinking about it more, because of the merges, I accept this only when I am forced to switch to work on 4.x branch after feature freeze — luci
But where do you commit the thing you are developping - innyour local or personal branches - and after do a bug commit where you lost the commit message? - sylvieg
But where do you commit the thing you are developping - innyour local or personal branches - and after do a bug commit where you lost the commit message? - sylvieg
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 |
|
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 |
|
|
Contributors to this page: marclaporte
,
sylvie
,
Kissaki
,
jonnybradley
,
luci
and
nyloth
.
Page last modified on Tuesday 09 March, 2010 16:09:27 UTC by marclaporte
.
Sidebar
Sidebar
To register
To have an account at this site, please register at Tikiwiki.org
, and then use that user name and password to log in here.

Last Comments