[fusionregistry commit] r16 - wiki
codesite...@google.com
Date: Sun Aug 3 21:48:16 2008
New Revision: 16
Added:
wiki/
wiki/releasemanagement.wiki
Log:
Created wiki page through web user interface.
Added: wiki/releasemanagement.wiki
==============================================================================
--- (empty file)
+++ wiki/releasemanagement.wiki Sun Aug 3 21:48:16 2008
@@ -0,0 +1,129 @@
+#summary Fusion Registry GPL Release Management
+#labels Phase-Implementation
+=Fusion Registry GPL Release Management=
+
+This document details the internal details and processes involved in releasing builds.
+
+==Internal Release Numbers==
+Fusion Registry uses an integer index system to identify release numbers. Each release requires a unique integer. The format is:
+{{{
+MmmNN
+}}}
+Where _M_ is the Major Version, _mm_ is the minor version, and _NN_ is the release number. Release numbers start at '00' increasing one digit per release.
+
+For example this could be the numbering scheme for future releases:
+{{{
+'30100' => '3.1.0 Beta 1'
+'30101' => '3.1.0 Beta 2'
+'30102' => '3.1.0 RC1'
+'30103' => '3.1.0 RC2'
+'30104' => '3.1.0 Final'
+'30200' => '3.2.0 Beta 1'
+'30201' => '3.2.0 Final'
+}}}
+
+The last 2 digits do not directly relate to the human readable version number of the release, as such in the example above '00' was for Beta 1, '01' was Beta 2, and so on.
+
+===In The Code===
+The internal release numbers and human readable version numbers are located in a few locations. The internal release number is called 'version_long', the human readable version number is called 'version_short'.
+
+_*/sources/components_public/fusionscripts/fusionregistry/upgrade/version_history.php*_
+
+This file contains an array that defines all the releases. The values defined here are only shown during the upgrade procedure.
+
+_*/sources/components_public/fusionscripts/fusionregistry/upgrade/upgrade_<version>/version_upgrade.php*_
+
+Each upgrade kit folder is named 'upgrade`_`' followed by the internal release number, for example 'upgrade_30003'. In the version_upgrade.php file the function do_cleanup() is responsible for updating the version numbers in the database.
+{{{
+$vers = array( 'version_long' => '30003',
+ 'version_short' => 'v3.0.3' );
+}}}
+
+_*/sources/components_public/fusionscripts/fusionregistry/install/sql/inserts.sql.php*_
+
+The installer is responsible for inserting the version numbers in the database:
+{{{
+('version_long', '30003');
+('version_short', 'v3.0.3');
+}}}
+These two values are used in the comparison with the running code to determine if there is a mismatch present. It is important that the values here exactly match the end-user loader and the ACP loader below.
+
+_*/sources/components_public/fusionscripts/fusionregistry/lib/core.php*_
+
+Near the beginning of class registry_core:
+{{{
+var $r_version_short = 'v3.0.3';
+var $r_version_long = '30003';
+}}}
+It is important these two values match the inserts.sql.php values above. If they do not match the code will raise an alert in the ACP that a version mismatch exists.
+
+_*/sources/components_acp/fusionscripts/fusionregistry/ad_registry_loader.php*_
+
+Near the beginning of the class ad_registry_loader:
+{{{
+var $r_version_short = 'v3.0.3';
+var $r_version_long = '30003';
+}}}
+It is important these two values match the inserts.sql.php values above. If they do not match the code will raise an alert in the ACP that a version mismatch exists.
+
+
+==Upgrade Kits==
+Each release that has an internal release number needs an upgrade kit. The most basic, and only required operation of an upgrade kit is to update the version numbers in the end-users' database. Other operations of an upgrade kit could include SQL queries to modify the database for any schema changes to support the new version, file manipulation, skin/database cleanup routines, etc.
+
+Each upgrade kit is stored here:
+/sources/components_public/fusionscripts/fusionregistry/upgrade/
+
+Each upgrade kit is a folder named 'upgrade`_`' followed by the internal release number, for example 'upgrade_30003'. The only required file is version_upgrade.php. The easiest way to create a new upgrade kit is to use an existing one as a template and change as needed.
+
+
+==Skin / Component Exports==
+There are two files in the build that need to be exported from within the forum ACP, the skin 'ipb_skin-fusionregistry.xml.gz' and the component 'fusionregistry_component.xml'. These two files should already exist in the repository and be up-to-date by the time a release is ready.
+When you are working with the skin and need to export it make sure you choose the option 'Export customizations in this skin only'. See the [versioncontrol Version Control - Locks] section for important skin note.
+
+
+==README / INSTALL / UPGRADE Files==
+Pretty self explanatory here, update these files as needed to assist end users on installing and upgrading.
+
+
+==Create Build==
+Copy the current code to an appropriate tag, for example 'rel_3_1_0_b1', 'rel_3_1_0_rc1', or 'rel_3_1_0'.
+
+To make the process of packaging up builds for release a lot easier use the 'release.sh' script from the /tools/ directory in SVN. The release.sh script takes a few parameters and will do all the work of exporting, compressing in different formats, and generating md5sums.
+
+==Create Changelog==
+Changelog's in the past have been of two varieties, a summarized list, and a detailed report. The choice of which to use kind of depends on the scope of changes in the release. Generally a new major release would have a summarized list detailing the new features, improvements, and bug fixes. A minor or bug fix release would usually get a detailed report.
+
+There is no magic bullet to creating a changelog, if a summarized list is desired, look at the svn log and try to capture in a precise list the major items of interest.
+
+To generate a very detailed changelog report containing exactly what files were changed and why, follow these steps...
+
+We need to determine the revision numbers for when the two tags were created, then use those revision numbers to create a log of all changes made to our baseURL. The baseURL depends on what we are trying to find changes for. If we want to know the changes made between bug fix releases on the bugfix_3_0_x branch, then /branches/bugfix_3_0_x is our baseURL; if we want to know the changes between two major releases, then /trunk is our baseURL.
+
+Why the different baseURL's? Because bug fix changes are checked into branches and not the trunk, if we used the trunk as our baseURL we would not capture the changes made on the branch.
+
+So our goal is to run this command
+{{{
+ $ svn log -v -rX:Y baseURL > Changelog
+}}}
+…where X and Y are the revisions from which the two tags were created. To discover X and Y, use the --stop-on-copy option when logging the history of each tag. No commits happen on tag directories, so the following commands should each produce exactly one log entry:
+{{{
+ $ svn log -v --stop-on-copy https:url/svn/tags/rel_3_0_3
+
+ r7 | copland007 | 2007-06-12 23:54:02 -0400 (Tue, 12 Jun 2007) | 1 line
+ …
+
+ $ svn log -v --stop-on-copy https:url/svn/tags/rel_3_0_4
+
+ r19 | copland007 | 2007-06-18 23:47:18 -0400 (Mon, 18 Jun 2007) | 1 line
+ …
+}}}
+So in this example, the values of X and Y are 7 and 19. Now you can view all changes between those two points in time:
+{{{
+ $ svn log -v -r7:19 https:url/svn/branches/bugfix_3_0_x > ChangeLog
+}}}
+If you don't want to see the verbose output remove '-v', to reverse the output change to '-r19:7', if you want to output to the screen and not to a file remove '> ChangeLog'
+
+An alternative GNU-style ChangeLog can be created using the '[http:_ch.tudelft.nl/%7Earthur/svn2cl/ svn2cl]' utility:
+{{{
+svn2cl --group-by-day --separate-daylogs --break-before-msg=2 -i -r "7:19" https:url/svn/branches/bugfix_3_0_x
+}}}
\ No newline at end of file