# SDP Release Process Overview ## Introduction This document describes the process used to release the Server Deployment Package (SDP). This is intended for staff developing the SDP. ## Preparation A dedicated SDP workspace should be used for releasing the SDP, separate from any you might use for SDP development. This dedicated release workspace should not contain any cruft files such as editor temp files. The release process mechanisms prevents known-cruft files from being added such as *~ files and .DS_Store files on Mac. Using a clean dedicated release workspace guarantees no local excess files can sneak into the packaging process. ## Procedure 1. Develop and test changes in dev branch. This will occur over time. 2. Verify that the SDP regression test suite is successful. 3. If not already done during development, create jobs and associate them with changelists in the `dev` branch, e.g. using `p4 fix -c SDP-`. We don't need a job for every change. Create jobs to cover the essentials of what changed. Folks who want the gory details can look at changelists, but folks looking only at jobs should get a good, albeit summarized, understanding of what's new in this release, and if appropriate, what to be aware of when taking this release. The first line of the job description will be incorporated into the release notes, so make the first line a good headline for the job. 4. Load the SDP tools shell environment. Change to the dir in your SDP workspace corresponding to `//guest/perforce_software/sdp/tools`, and do `source ./env.sh` in that directory. 5. Ensure the `dev` branch is updated from main. This ensures any hot fixes that my have been made directly in `main` branch are considered for incorporation in the formal release.
 $ p4 merge -n -b perforce_software-sdp-dev
 All revision(s) already integrated.
 
If there is anything to merge, take care of it in your regular SDP development workspace, not the release workspace. If needed, file new jobs and associate them with changes. 6. Ensure generated documentation is current. Run the `gen_script_man_pages.sh -submit` and observe the output. It may or may not create a new changelist in `//guest/perforce_software/sdp/dev/doc/gen/...`, depending on whether the underlying scripts have changed since they were last generated. Next, refresh the AsciiDoc files that incorporate the generated manual pages into higher level docs. Change to the the local folder in your workspace corresponding to `//guest/perforce_software/sdp/dev/doc`, and run:
make clean
make
p4 rec && p4 -s submit -d "Updated AsciiDoc-generated files." ...
7. Run the `rel_notes.sh` script to update the Version and Release Notes files in the dev branch. If the jobs listed aren't complete enough, revert the `Version` and `doc/ReleaseNotes.md` files, update the job descriptions, and try again. If this is a new major release, manually update the section, "What's New in ". Summarize what to be aware of when taking this release, summarize what's in the release, and document details to be aware of when upgrading to this release. This script is interactive and requests the major version, e.g. 2020.1 (proposing as a default whatever the previous value was). It takes no command line arguments. The `rel_notes.sh` wants your workspace to be clean, with the latest files sync'd, nothing checked out in the `dev` and `main` branches, and that a `p4 status` command reporting nothing to reconcile. ***WARNING***: If you need to do a partial release (i.e. if you need to hold some changes back in the `dev` branch), be sure to remove jobs referencing files you do not intend to promote. Note that partial releases are discouraged. ***WARNING***: If a partial release was done previously and files are now ready to be released, you'll need to add those jobs to the release notes manually. Doing a partial release will confuse the mechanism used in `rel_notes.sh` to determine what jobs were fixed since the last release, as it does a `p4 fixes` command in the dev branch looking for fixes since the last release changelist number in the Version file. Even a partial release updates the changelist number, and thus will require manual intervention to get the list of jobs correct. The `rel_notes.sh` script leaves the Version and Release Notes files checked out in a pending changelist for you to review. Submit that change manually when ready, e.g. after adding the "What's New in " content. 8. Push the files to main. Change to the `dev` branch directory in your workspace. Run `mdcu.sh` (Merge Down/Copy Up) script, which takes no arguments and is not interactive. That script creates a pending changelist with the Copy Up main. Massage the generated pending changelist description if desired. **WARNING FOR PARTIAL RELEASES**: If this is to be a partial release, revert any files that are not ready to be released from the main branch. Also be sure the reverted files correlate to any jobs removed for a partial release. Next, submit the generated pending changelist manually. 9. After running this script, run `package_downloads.sh`. This puts tar and zip files into the downloads folder. Submit the generated changelist manually.