RELEASE BUILD PROCEDURE FOR P4DTI Gareth Rees, Ravenbrook Limited, 2000-10-17 1. INTRODUCTION This is the procedure for building a release of the Perforce Defect Tracking Integration from the version sources. The readership of this document is anyone developing the integration. This document is not confidential. All pathnames here are relative to "//info.ravenbrook.com/project/p4dti/". If you're using cygwin to run the p4 commands, remember to alias p4='p4 -d "`cygpath -w \"$PWD\"`"' or put this in your .bashrc. 2. PROCEDURE 2.1. SETTING UP FOR RELEASE 2.1.1. Choose a release name of the form "VERSION.N" (for example, 0.3.0). VERSION is the number of the version you're releasing. N is the first unused release number (starting at zero). Look in the index of releases (release/index.html) for existing release numbers for your version. 2.1.2. Ensure that the "version/VERSION/readme.txt" file has an up-to-date description of the release you intend to build, contains the correct release, the list of known defects, and a summary of changes and new features. The list of known defects should be based on the list of outstanding critical and essential jobs: p4 jobs -e 'project=p4dti status=open (priority=critical|priority=essential)' The known_issues.py script can be used to generate and format this list of outstanding jobs. The summary of changes and new features should be based on the list of jobs fixed to "closed" between the last version and this one: p4 fixes -i master/...@CHANGELIST,CHANGELIST | grep -v ')$' | cut -d ' ' -f 1 | sort -u The changelists for each version come from the version index. MAKE SURE TO CHECK IT IN BEFORE YOU CONTINUE. 2.1.3. Sync the version sources to the changelist from which you intend to build the release. Sync the version sources to a clean area of the disk, to be sure that there are no extraneous files around. p4 sync version/VERSION/...#none rm -rf version/VERSION p4 sync version/VERSION/...@CHANGELIST Usually you will be building the release from the head revision of the version sources. In this case, you need to get the changelist number. Use "p4 counter change" to get the head changelist number, and use that for the rest of the procedure. 2.1.4. Branch the "readme.txt" file from the version sources to the "release/RELEASE" directory. DO NOT SUBMIT YET. p4 integrate version/VERSION/readme.txt release/RELEASE/readme.txt 2.2. MAKING THE TEAMTRACK RELEASE 2.2.1. To build teamtrack.dll: Run Microsoft Visual C++ 6.0. Select File -> Open Workspace. Select version/VERSION/code/p4dti.dsw. Check that the "teamtrack" and "tsapi" projects are using the "Win32 Release" configurations (right click on the project; select Set As Active Project; click on the Build menu; select Set Active Configuration; select Win32 Release). Make teamtrack the active project (right click on the project; click on the Build menu; select Set As Active Project). Click on the Build menu; select Build teamtrack.dll. 2.2.2. Launch WinZip and create a new archive called "p4dti-teamtrack-RELEASE.zip" in the directory "release/RELEASE". Add the files listed below. Be sure _not_ to store full paths in WinZip (an option in the "Add" dialog). version/VERSION/code/replicator/*.py version/VERSION/code/replicator/teamtrack.dll Add the manuals with partial path names, by selecting version/VERSION/manual/{ig,mg,ag,ug} then turn on the "Include subfolders" option, then select "Add with wildcards". Make sure *not* to include these files: - version/VERSION/manual/ag/*.awk - version/VERSION/manual/index.html 2.2.3. Make a self-extracting archive called "p4dti-teamtrack-RELEASE.exe" from "p4dti-teamtrack-0.3.0.zip" (in the same directory), by selcting Actions -> Make .EXE File. Specify the default "unzip to" folder as "C:\Program Files\P4DTI". 2.2.4. Add the archive and self-extracting archive to Perforce. DO NOT SUBMIT YET. p4 add release/RELEASE/p4dti-teamtrack-RELEASE.exe p4 add release/RELEASE/p4dti-teamtrack-RELEASE.zip 2.3. MAKING THE BUGZILLA RELEASE [Nothing here yet] 2.4. SUBMITTING THE RELEASE 2.4.1. Edit the index of releases (release/index.html) and add the release to the table, in a manner consistent with previous releases. 2.4.2. Edit the index of versions (version/index.html) and add the release to the list of releases for VERSION, in a manner consistent with previous releases. 2.4.3 The "p4 opened" command should show something like this: //info.ravenbrook.com/project/p4dti/release/RELEASE/p4dti-teamtrack-RELEASE.exe#1 - add default change (xbinary) //info.ravenbrook.com/project/p4dti/release/RELEASE/p4dti-teamtrack-RELEASE.zip#1 - add default change (binary) //info.ravenbrook.com/project/p4dti/release/RELEASE/readme.txt#1 - branch default change (ktext) //info.ravenbrook.com/project/p4dti/release/index.html#17 - edit default change (text+ko) //info.ravenbrook.com/project/p4dti/version/index.html#14 - edit default change (text+ko) 2.4.4. Submit these changes with the comment "Made release RELEASE." 2.4.5. Inform the project manager by e-mail. A. References [RB 2000-10-13] "P4DTI release build and installation" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2000-10-13; . [GDR 2000-10-16] "Re:P4DTI release build and installation" (e-mail message); Gareth Rees; Ravenbrook Limited; 2000-10-16; . [GDR 2000-10-17] "Build report for release 0.3.1" (e-mail message); Gareth Rees; Ravenbrook Limited; 2000-10-17. [RB 2000-11-17] "Using Perforce labels for releases" (e-mail message); Richard Brooksby; Ravenbrook Limited; 2000-11-17. B. Document history 2000-10-17 RB Created based on e-mail procedure [RB 2000-10-13]. 2000-10-17 GDR Added corrections from [GDR 2000-10-16] and [GDR 2000-10-17]. 2000-10-19 RB Added steps for handing the readme.txt. Changed bullets to numbers in the procedure. Corrected the order of the "label" and "sync" steps. 2000-11-17 RB Discontinued use of Perforce labels in favour of changelists. See [RB 2000-11-17]. 2000-12-01 RB Updated references to the "SAG" to "AG" since it's now called the Administrator's Guide. 2000-12-05 GDR Reorganized into sections and added Bugzilla section. Updated for version 0.4: use release configuration for teamtrack.dll; don't include debugging or AppleWorks files. Explained how to get the lists of known defects, changes and new features. Listed the files that one would expect to have on submit so you can check that you've done everything. 2000-12-07 GDR Added reference to known_issues.py script. 2000-12-08 GDR Added more detail about Microsoft Visual C++. Added instruction to check in readme.txt before continuing.