[Show/Hide Right Column]

Print

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.

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)

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

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

Check changes made by the release script before validating commits
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

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

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
  2. None are forgotten

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

external Make sure sites are still active.

quick script to check all http links in templates
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

  • 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

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

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

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
alias

Contributors to this page: Marc Laporte2679 points  , sylvie2503 points  , nyloth584 points  , luciash d' being1825 points  , Kissaki313 points  and jonnybradley1253 points  .
Page last modified on Friday 13 August, 2010 15:28:00 UTC by Marc Laporte2679 points .

Search Wishes (subject only) [toggle]

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.


Show php error messages
 
PHP (5.2.10-2ubuntu6.4) NOTICE (E_NOTICE):
File: comments.php
Line: 272
Type: Undefined variable: tiki_p_forum_vote
PHP (5.2.10-2ubuntu6.4) ERROR (E_USER_WARNING):
File: lib/core/lib/TikiFilter.php
Line: 77
Type: Filter not found: description