DocProdRelease

Performing Production SLASH2 Releases

This document describes details for building and shipping a production SLASH2 software release.

Preparing a Release

Ensure a full source build works:

$ cd projects
$ make build >/dev/null

Any errors should be corrected and warnings paid attention to.

Now, check if any automatically regenerated files need committed:

$ make scm-status

Look for files marked M denoting local modifications and commit as appropriate. Failure to do so will leave local changes in the production clones that may subsequently create conflicts.

Next, ensure the unit test suite passes:

$ make test >/dev/null

If this completes without errors, record the version number(s) of any repositories in the production wiki/journal:

$ cd slash2
$ make printvar-REPO_VERSION

Deploying a Release

The SLASH2 source tree should never be built as the root user. The reason is because pulling git updates from private repositories (as not all repos are public/GitHub) will require your user account, so hardcoding your username will prevent other administrators from being able to perform the updates.

First Time Installation

root# cd /local/src		# or whereever the tree is desired
root# mkdir p
root# chgrp $staff p
root# chmod g+ws p
root# cd p
root# sudo -u user -s
user$ umask 2
user$ umask 2

Fixing a tree with bad file permissions

If updates or modifications were made without the proper umask setting or done as root, ownership and/or permissions will need to be fixed:

root# cd /local/src/p
root# chgrp -R $staff .
root# chmod -R g+w .
root# find . -type d -exec chmod g+s {} \;

root# rm -rf $tmp/psc.obj

Updating Existing Installations

src-upd