How to improve the release process

This page is to discuss and plan on how to make How to release easier and less time consuming. Most of them should not only be done at release time but also as part of the Continuous Integration.

Check DB files

• Script to automate what are now manual steps for How to release (Drop Table, MyISAM, lacking _tiki.sql suffix)

Script to test preferences

php doc/devtools/prefreport.php > prefreport.csv

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 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)
3. There are no duplicates like Commit #35237

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
   • done
3. Make a list of all possible feature_names appearing lib/setup/prefs.php
   • done

How to improve the script

Check links

This is also something that should be added to Tiki as feature (on Tiki content)

script to check external links

to doc.tiki.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.tiki.org/Restore+Help+Pages

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

lessermagicreport.php can do plugins

to all other sites

Detect http:// and similar.

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

Script to detect invisible weirdness in files

dos2unix

find . -iname '*.*' | xargs dos2unix

Taken from: http://serverfault.com/questions/205499/how-to-do-dos2unix-to-tpl-recursively-in-linux

But don't touch externals...

BOM

• http://svn.fckeditor.net/FCKeditor/trunk/_dev/php_bom_finder.php
• http://code.google.com/p/dompdf/source/diff?spec=svn434&r=434&format=side&path=/trunk/dompdf/include/dompdf.cls.php

Script to upload to SourceForge.net

• like LimeSurvey

Other ideas & script

• Check presence of index.php and .htaccess in all directories
  • Check for empty directories
• Replace changelog.txt with a link to tiki.org/Changelog, which itself redirects to SourceForge's SVN view
• Create a shell script to empty caches (Maybe there is one in TRIM?)
• Test run with http://profiles.tiki.org/Test_All_Features to see if any features/plugins/modules are crashing Tiki
• Add MD5s
• php doc/devtools/release.php --testrun
• Improve handling of Security Check exceptions
  • security script: list of plugins with no validation?

Discussions

To branch or not to branch

• When to branch

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)