TDM Release Mechanics: Difference between revisions

From The DarkMod Wiki
Jump to navigationJump to search
No edit summary
Line 9: Line 9:
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN.  
At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN.  


Once the deadline arrives, the '''release branch''' is created:
Once the deadline arrives, the '''release branch''' is created: [[Image:Create release branch.png|right]]
* Update your darkmod working copy.
* Update your darkmod working copy.
* Update the darkmod_src repository too.
* Update the darkmod_src repository too.
Line 21: Line 21:
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch.  
At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch.  


Important: commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.
'''Important:''' commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been ''switched'' to the release branch. ''Your commits will go to the branch'', keep that in mind. To learn how to ''merge'' stuff between the trunk and the release branch, see below.


= Compile Game Binaries =
= Compile Game Binaries =

Revision as of 07:25, 15 December 2010

This article describes the process of creating a TDM point release. It will be fleshed out over the next few days/weeks.

The team is using a version control system (SVN) for development, and the objective is to create a set of PK4 file from the repository which can be uploaded to the TDM mirrors. Let's go through this step by step:

Development

Just for the sake of completeness, this step includes the regular development between two TDM releases. This day-to-day development is always happening on the trunk, so all commits are ending up there. Stuff gets broken, stuff gets fixed, stuff gets evaluated, some might be ripped out again.

Branching off

At some point the team decides that it might be time for a new release - a so-called branch date (some sort of semi-freeze) is suggested and agreed upon. To this date, team members are supposed to wrap up their pending changes and commit them to the trunk. About two to three weeks are long enough of a time span for people to get everything into SVN.

Once the deadline arrives, the release branch is created:

  • Update your darkmod working copy.
  • Update the darkmod_src repository too.
  • Right-click the darkmod folder to create the branch
    • Select SVN > Branch/Tag...
    • A new dialog appears asking for a URL. Enter a URL like this: https://<darkmod_server_here>/svn/darkmod/branches/release1.xx where xx is replaced by whatever version the next release will be.
    • You'll probably want to switch to the new branch once it is created, so make sure the check button at the bottom of the dialog is active.
    • Hit OK to let the SVN server create the branch (the server will create a copy of the trunk, placing it at the URL you specified. It might be notable that the files are not physically copied, the branch requires a marginal amount of additional server space).
  • The same should happen with the darkmod_src repository, the code needs to be frozen as well. Perform the same steps as above, using the URL scheme https://<darkmod_server_here>/svn/darkmod_src/branches/release1.xx

At this point there are two new branches, one for the darkmod repo, one for darkmod_src. Consider them a snapshot of the trunk at the point in time you created the branch.

Important: commits to the trunk won't affect this newly created branch. The team members not involved in the release can just continue working as usual. Also note that if you as branch creator had the check button ("switch working copy") activated, your working copy has been switched to the release branch. Your commits will go to the branch, keep that in mind. To learn how to merge stuff between the trunk and the release branch, see below.

Compile Game Binaries

Before the PK4 files can be assembled into a release package, the code from darkmod_src needs to be re-compiled for the Windows and Linux platforms. This is to make sure that the release is built from the most recent (and hopefully most stable) source. If you're not a coder, you can either ask your fellow coders to switch to the branch and compile the tdm_gameNN.pk4 for you, or you can bite the bullet and follow the TDM Compilation Guide to compile it yourself. As Windows user, I recommend setting up an Ubuntu 10.04 32-Bit instance in VirtualBox. The downside of using virtualisation is that compilation takes 30-40 Minutes depending on your CPU power, but you at least don't need a dual-boot setup, let alone a second PC.

Make sure you compile a release build (debug builds are terribly slow), I also recommend re-compiling everything from scratch everytime you build a binary (Run scons -c in Linux or choose Rebuild Solution in VC++), even if it takes longer, just to make sure.

Once compiled, make sure to commit the tdm_game01.pk4 and tdm_game02.pk4 files to the branch.

Generate the Manifest

Once you know that the game binaries (tdm_gameNN.pk4 files) are up to date and checked into the release branch, go ahead and build the manifest. The manifest is a huge text files listing all the files that are nominated to go into the release. Not all files in SVN are supposed to be released (like test files, test maps, other broken or unfinished stuff), so we need a white list.

To build that manifest there exists a Perl script extract-assets.pl in the devel, which traverses your repository and collects the files. To run that script, one is bound to Linux at the moment, as the "file-is-in-SVN" check fails in Windows. I recommend using VirtualBox again, but be warned that building the manifest takes over an hour this way (I've Ubuntu set up on my second laptop, which takes about 10 Minutes to compile the manifest). Run the command by typing this in your darkmod folder:

perl devel/extract-assets.pl darkmod

After this step the file devel/manifests/darkmod.txt has been updated. You might want to review the modifications the script made to that file and commit it to the release branch if you're satisfied.

Note: you need to re-build the manifest everytime a file gets added or removed from the release branch. You don't need to rebuild it if a texture file gots changed, for example.

What is included in the Manifest

The extract-assets Perl script is using the file devel/manifests/darkmod_maps.txt to decide whether to include or exclude stuff. In a first internal step the script will include all files in specific folders:

# Include all these files (but without parsing them like maps), each
# statement will include files (from SVN) in that folder:
INCLUDE def/
INCLUDE dds/
...
INCLUDE video/
INCLUDE xdata/

As visible in the above example, the sharp character # is used to denote comments. Put that at the beginning of a line to disable the statement.

As next step the algorithm will exclude certain files matching the regular expressions in EXCLUDE statements like this:

EXCLUDE dds/darkmod/test

In 95% of the cases it's enough to just specify the path of the files you want to exclude (use forward slashes), but you can do more fancy stuff like this:

EXCLUDE models/md5/chars/undead/revenant/.*.md5anim
EXCLUDE ^(dds/)?models/md5/chars/undead/revenant

The first line will exclude all MD5ANIM files in the revenant folder. The second line will exclude all files in models/md5/chars/undead/revenant and the ones in dds/models/md5/chars/undead/revenant (the dds/ part is marked to be optional).

In summary, all files that are INCLUDE'd as denoted above and afterwards manage to get through the hundreds of lines of EXCLUDE filters will end up in the manifest file.

TODO

Glossary

  • Release Fileset: the PK4 files forming the actual release.
  • SVN: an acronym for Subversion, a version control system
  • Commit: The process of a team member uploading files to the SVN repository - a commit always creates a new SVN revision.
  • Mirrors: The servers where the PK4 files are stored for download by the updater.
  • updater: The TDM Updater executable, used for downloading and updating TDM.
  • binary: Source code is compiled into so-called binaries. This can be an executable (.exe) file or a module (.dll/.so).
  • darkmod_src: The code repository holding all the TDM source files, including the tdm_update application.
  • branch: A tree in the SVN repository. Several branches can co-exist side-by-side without interfering.
  • trunk: The main branch where all the ongoing development is happening.