Difference between revisions of "Release Build Process"
From FreeSpace Wiki
(Accidentally removed an important space.) |
|||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | <nowiki>1) (One time) Create branch for new release. This is an entirely remote op and can be done from anywhere, by anyone with write access. | + | <nowiki>Steps 1-5, and 7 are now encompassed by release.pl found at https://svn.icculus.org/fs2open/trunk/nightly-build/ folder. This greatly speeds up the release process. |
+ | The script supports the new Git backend, and the commands here have been updated to take that into account. However, the steps below were written with SVN in mind. | ||
+ | The descriptions of the steps that the release script runs are still valid, and could be updated with git-relevant examples at some point. | ||
+ | |||
+ | The script is generally run with the following options on each platform, and in this order: | ||
+ | |||
+ | Mac (RC1 only): ./release.pl --lastversion <OLDVERSION> --nextversion <NEWVERSION> --nextsubversion RC1 --lastreleaserevision 000000 --createbranch <release base branch (ex. origin/master)> | ||
+ | * Specifying lastversion causes it to do version replacement with the given info and generate versioning commit. | ||
+ | * Specifying createbranch causes it to create a new branch on the VCS, and with git, a branch reference to fork from must be specified. | ||
+ | Mac: ./release.pl --lastversion <NEWVERSION> --lastsubversion RCx --nextversion <NEWVERSION [--nextsubversion RCx] --lastreleaserevision <OLDREVISION> | ||
+ | * After RC1, the branch exists so we only specify the necessary versions to accomplish the desired replacements and versioning commit. | ||
+ | Linux: ./release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] --doarchive | ||
+ | * Specifying doarchive causes the code to generate and upload the source code archive in addition to the build. | ||
+ | FreeBSD: ./release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] | ||
+ | Windows: perl release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] --message "Release message here, its existence will lead to the forum post." | ||
+ | If the Windows one gives trouble with arguments, read http://www.perlmonks.org/?node_id=1054513 for help. | ||
+ | |||
+ | |||
+ | 1) (One time) Create branch for new release. This is an entirely remote op and can be done from anywhere, by anyone with write access. | ||
svn copy [-r REV] svn://svn.icculus.org/fs2open/trunk/fs2_open svn://svn.icculus.org/fs2open/branches/fs2_open_<VERSION> -m "Copy trunk r<REV> to <VERSION> branch." | svn copy [-r REV] svn://svn.icculus.org/fs2open/trunk/fs2_open svn://svn.icculus.org/fs2open/branches/fs2_open_<VERSION> -m "Copy trunk r<REV> to <VERSION> branch." | ||
Line 88: | Line 106: | ||
9) Make other forum and news posts as necessary (Announcements, ModDB for final releases possibly, etc). | 9) Make other forum and news posts as necessary (Announcements, ModDB for final releases possibly, etc). | ||
− | + | 10) Update FSO Installer source files to serve up the new release. Use the checksum files uploaded by the release script to make this easy.</nowiki> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 20:05, 7 March 2016
Steps 1-5, and 7 are now encompassed by release.pl found at https://svn.icculus.org/fs2open/trunk/nightly-build/ folder. This greatly speeds up the release process. The script supports the new Git backend, and the commands here have been updated to take that into account. However, the steps below were written with SVN in mind. The descriptions of the steps that the release script runs are still valid, and could be updated with git-relevant examples at some point. The script is generally run with the following options on each platform, and in this order: Mac (RC1 only): ./release.pl --lastversion <OLDVERSION> --nextversion <NEWVERSION> --nextsubversion RC1 --lastreleaserevision 000000 --createbranch <release base branch (ex. origin/master)> * Specifying lastversion causes it to do version replacement with the given info and generate versioning commit. * Specifying createbranch causes it to create a new branch on the VCS, and with git, a branch reference to fork from must be specified. Mac: ./release.pl --lastversion <NEWVERSION> --lastsubversion RCx --nextversion <NEWVERSION [--nextsubversion RCx] --lastreleaserevision <OLDREVISION> * After RC1, the branch exists so we only specify the necessary versions to accomplish the desired replacements and versioning commit. Linux: ./release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] --doarchive * Specifying doarchive causes the code to generate and upload the source code archive in addition to the build. FreeBSD: ./release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] Windows: perl release.pl --nextversion <NEWVERSION> [--nextsubversion RCx] --message "Release message here, its existence will lead to the forum post." If the Windows one gives trouble with arguments, read http://www.perlmonks.org/?node_id=1054513 for help. 1) (One time) Create branch for new release. This is an entirely remote op and can be done from anywhere, by anyone with write access. svn copy [-r REV] svn://svn.icculus.org/fs2open/trunk/fs2_open svn://svn.icculus.org/fs2open/branches/fs2_open_<VERSION> -m "Copy trunk r<REV> to <VERSION> branch." # REV is only needed after copy if not just copying the latest HEAD revision in trunk. 2) (Once per platform) Checkout the branch. cd <CODE DIRECTORY> svn co svn://svn.icculus.org/fs2open/branches/fs2_open_<VERSION> fs2_open_<VERSION>_svn 3) (Once per release) Commit a output filename/versioning commit. https://svn.icculus.org/fs2open?view=rev&revision=9638 should be a complete diff of everything that should be modified. Since the pilot code, this has been simplified a bit as far as project files are concerned. Windows project version strings are a bit different (more consistent, fewer). Most consist of replacing 2_open_<PREV_VERSION> with 2_open_<NEXT_VERSION>. A search and replace through all the necessary files will cover most of the build output filenames for the Windows project files. For instance: s/2_open_3_6_19/2_open_3_7_0_RC1 That will cover all instances of fred2_open_3_6_19[-DEBUG], fs2_open_3_6_19[-DEBUG], and wxfred2_open_3_6_19[-DEBUG]. For enabling text-to-speech and voice recognition in MSVC_2008, open the Fred2.vcproj, Freespace2.vcproj, and code.vcproj. In all three, you need to: s/_SECURE_SCL=0;_HAS_ITERATOR_DEBUGGING=0;"/_SECURE_SCL=0;_HAS_ITERATOR_DEBUGGING=0;FS2_SPEECH;FS2_VOICER;" There should be 18 replacements total, 6 per file. In Freespace2.vcproj, you must also: s/_VC08;/_VC08;FS2_VOICER; There should be six of those. For the Xcode projects, the InfoPlist.strings files are binary, but editable in most decent editors and should be obvious what needs to be changed. The project.pbxproj files just need the CURRENT_PROJECT_VERSION fields updated from, for example, 3.6.19-trunk to 3.7.0-RC1, etc. BE SURE TO GET THE CODEBLOCKS Freespace2 project file. It was somehow still missed in the 9638 commit. 4) (Following instructions are once per release per platform) Export at the desired revision from the branch checkout. cd <CODE DIRECTORY> svn up fs2_open_<VERSION>_svn svn export fs2_open_<VERSION>_svn fs2_open_<VERSION>[_RCx] # (Linux only) tar -cvzf fs2_open_<VERSION>[_RCx]_src.tgz fs2_open_<VERSION>[_RCx] md5sum fs2_open_<VERSION>[_RCx]_src.tgz > fs2_open_<VERSION>[_RCx]_src.md5 # Upload source export and md5 to builds folder. 5) Follow the specific platform's build method. Windows: Currently use MSVC 2008. Open the .sln, and batch build all configs (Release and Debug Standard, SSE, SSE2) for Freespace2 and Fred2. -or- "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Release|Win32" && \ "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Debug|Win32" && \ "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Release SSE|Win32" && \ "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Debug SSE|Win32" && \ "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Release SSE2|Win32" && \ "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcpackages\vcbuild" /nocolor /nologo /rebuild Freespace2.sln "Debug SSE2|Win32" Copy the 2 release exes into the respective debug folder, and archive the 4 exes, the 2 map files, and the 2 pdb files using standard zip compression. You should end up with three files: fs2_open_<VERSION>[_RCx].zip (SSE2), fs2_open_<VERSION>[_RCx]_SSE.zip, and fs2_open_<VERSION>[_RCx]_NO-SSE.zip. MD5 the three zip files into fs2_open_<VERSION>[_RCx].md5. Upload these 4 files to the mirrors under builds/WIN. OSX: Currently use Xcode 5.1.1. cd <CODE DIRECTORY>/fs2_open_<VERSION>[_RCx]/projects/Xcode tar -xvzf Frameworks.tgz /<xcodebuild_path>/xcodebuild -configuration Release && /<xcodebuild_path>/xcodebuild -configuration Debug # Copy .apps from build/Debug and build/Release to a folder names FS2_Open <VERSION>[ RCx]. mkdir ~/Desktop/FS2_Open\ <VERSION>[ RCx] cp -rf build/Release/FS2_Open.app ~/Desktop/FS2_Open\ <VERSION>[\ RCx]/FS2_Open\ <VERSION>[\ RCx].app cp -rf build/Debug/FS2_Open\ \(debug\).app ~/Desktop/FS2_Open\ <VERSION>[\ RCx]/FS2_Open\ <VERSION>[\ RCx]\ \(debug\).app # Use hdiutil to create an archive named FS2_Open-<VERSION>[_RCx].dmg. hdiutil create -srcfolder ~/Desktop/FS2_Open\ <VERSION>[\ RCx] ~/Desktop/FS2_Open-<VERSION>[_RCx].dmg # MD5 the .dmg file into FS2_Open-<VERSION>[_RCx].md5. md5 ~/Desktop/FS2_Open*.dmg > ~/Desktop/FS2_Open-<VERSION>[_RCx].md5 # Upload these 2 files to the mirrors under builds/OSX. Linux/FreeBSD: Use whichever latest GCC/Clang is available and working. cd <CODE DIRECTORY/fs2_open_<VERSION>[_RCx] ./autogen.sh --enable-debug && make && cp code/fs2_open_<VERSION>[_RCx]_DEBUG ../ && make clean && make distclean && ./autogen.sh && make && cp code/fs2_open_<VERSION>[_RCx] ../ # Archive the fs2_open_<VERSION>* binary files into one fs2_open_<VERSION>[_RCx].tar.bz2 file. cd tar -cvjf fs2_open_<VERSION>[_RCx].tar.bz2 fs2_open_<VERSION>[_RCx]_DEBUG fs2_open_<VERSION>[_RCx] # MD5 the bz2 file into fs2_open_<VERSION>[_RCx].md5. md5sum fs2_open_<VERSION>[_RCx].tar.bz2 > fs2_open_<VERSION>[_RCx].md5 # Upload these 2 files to the mirrors under builds/LINUX or builds/FREEBSD, accordingly. 6) Update Mantis versions. If making a final release, be sure to make a released version for the next trunk version. Also for finals, bump any remaining Fix For <VERSION> to the next release version. 7) Make the main forum release post. Use previous release post as template, update all filename links, MD5s, Known Issues, and changelog. Sticky it. Unsticky previous RC posts if there was one. Irrelephant previous RC posts. Unsticky previous final release post if new final release post. 8) Update SCP website with news post, and links for a final release. 9) Make other forum and news posts as necessary (Announcements, ModDB for final releases possibly, etc). 10) Update FSO Installer source files to serve up the new release. Use the checksum files uploaded by the release script to make this easy.