NewRelease

pre-release checklist

First make sure, that all necessary changes are already committed into the repository:

• Variable inc/config.php:$max_dict_key must be equal to the maximum value of key found at the end of inc/dictionary.php.
• Function database.php:getDictStats() must enumerate all chapter IDs, which are listed in install/init-dictbase.sql:Chapter (install.php:get_pseudo_file():case 'dictbase' in version 0.19.0) otherwise the stats are shown wrong.
• All release notes, if any, must appear both in upgrade script and in the README.
• Current date must be present on the version line of ChangeLog.
• Make sure, that upgrade.php has new version listed in $versionhistory and executeUpgradeBatch(). It is normal to accumulate updates in executeUpgradeBatch() long before the release, this way on the release day you will have nothing to do in upgrade.php. But if you had no changes to DB since the last release, you are likely to see there changes missing. Just make sure the new version is in both places anyway.
• Bump up CODE_VERSION in inc/config.php and DB_VERSION in install.php:get_pseudo_file(). DON'T do this unless you really intend to make a release right now.
• svn stat; svn commit

Now export the codebase from the trunk (or maintenance branch, whichever you are releasing from) and test it.

# export --force in case the target directory already exists
svn export https://racktables.svn.sourceforge.net/svnroot/racktables/branches/maintenance-0.19.x .

• The application must be able to install itself with own installer. Once this is found working, dump the database:

mysqldump --extended-insert=FALSE --order-by-primary racktables_db > ~/tmp/dump-fresh.sql

• The release being tested must detect and upgrade a database from the previous release(s) correctly. Load (demoreload.sh) the database with the previous release data, then upgrade it with the current upgrader, then dump the DB. Now compare to the previous dump, there must be no meaningful differences.

mysqldump --extended-insert=FALSE --order-by-primary racktables_db > ~/tmp/dump-upgraded.sql
diff -u ~/tmp/dump-fresh.sql ~/tmp/dump-upgraded.sql

• Test the source as much as you find possible.
• Demo data should also be loadable and functional (for this a valid init-full SQL dump must exist in contribs).

racktables/contribs/demoreload.sh X.Y.z racktables_db

• Look into the error log of the server you used for the tests. There shouldn't be any error/warning messages.

The above rounds may happen repeated more, than once, until everything is fixed consistently.

the release itself

# from trunk (beta testing releases):
svn cp \
https://racktables.svn.sourceforge.net/svnroot/racktables/trunk \
https://racktables.svn.sourceforge.net/svnroot/racktables/tags/RackTables-0.Y.z

# from maintenance (stable releases):
svn cp \
https://racktables.svn.sourceforge.net/svnroot/racktables/branches/maintenance-0.Y.x \
https://racktables.svn.sourceforge.net/svnroot/racktables/tags/RackTables-0.Y.z

rolling out

• Make a tarball:

svn export https://racktables.svn.sourceforge.net/svnroot/racktables/tags/RackTables-X.Y.z
tar czf RackTables-X.Y.z.tar.gz RackTables-X.Y.z

• Upload the tarball to SF FRS (from browser or by other means).
• In MantisBT mark version as released (Manage, Manage Projects, RackTables, Versions).
• Log into SF shell service:

ssh -t YOUR_USERNAME,racktables@shell.sourceforge.net create

• Edit (vim) /home/project-web/racktables/htdocs/header.php to update $lastrelease. Test the "download" link to work after that.
• Post a Freshmeat release announce here.
• Send a letter to the racktables-users list, if necessary.
• Update demo.racktables.org to the current release ($demorelease will need an update).