HTCondorWiki: Release Punch List

 
 {section: Everything Else}
 
+There are two main phases of the actual release:
+
+1: Preliminary work to freeze the code, make a release branch, etc. (this can take a few days, so start early)
+1: Release process given a valid build candidate
+
+{subsection: Preliminary Work}
+
+1: Coordinate a development code-freeze. This involves chasing down people who are trying to finish bug fixes, new features (if it's a development release), porting, or any other core development that is slated for a given release.
+
+1: Ensure that the parent branch (e.g. =V7_0-branch=) is building properly on all platforms. If any platforms aren't building, you need to either solve it yourself or track down the person who broke the builds and get them to fix it immediately. This can take days, so _start early_!
+
+1: Notify the CS department. Send email to the =uwcs-condor@cs.wisc.edu= list announcing our plans for the pool upgrade. We like to give users at least a few days notice so that if there are important paper deadlines, etc, they have time to finish their jobs, or to let us know they need us to delay the upgrade.
+
+1: Make a release branch. The main thing to know is that the branch should have the name =VX_Y_Z-branch=. Here's an example of the steps for a 7.0.3 release, from a known good NMI tag (assuming your working directory is inside of a close of CONDOR_SRC.git):
+*:: The preferred method for making a release branch is from a known good build tag on NMI.
+{code}
+git branch V7_0_3-branch BUILD-V7_0-branch-2008-6-24
+git push origin V7_0_3-branch
+edit src/CVS_Tags on V7_0-branch to document the new branch.
+git diff to check your change, which should only be to the one file
+git commit -a -m "documented V7_0_3-branch tag for 7.0.3 release"
+git push origin V7_0-branch
+{endcode}
+*::or, if you'd like to make the branch off of the V7_0-branch:
+{code}
+git branch V7_0_3-branch origin/V7_0-branch
+git push origin V7_0_3-branch
+edit src/CVS_Tags on V7_0-branch to document the new branch.
+git diff to check your change, which should only be to the one file
+git commit -a -m "documented V7_0_3-branch tag for 7.0.3 release"
+git push origin V7_0-branch
+{endcode}
+1: Fix the version string in the release branch. However, in this case, the goal is to remove the "=PRE-RELEASE=" and other junk from the version string so you're left with an official version string for the final release.
+*:: =git checkout V7_0_3-branch=
+*:: Edit =src/condor_c++_util/condor_version.cpp=
+*:: Set the version string to: ="$CondorVersion: 7.0.3 " __DATE__ BUILDIDSTR " $";=
+*:: =git diff= (to verify the change before you commit it)...
+*:: =git commit -a -m "set official version string for 7.0.3"=
+*:: =git push origin V7_0_3-branch=
+
+1: Update =src/condor_c++_util/condor_version.cpp= on the main-line development branch (e.g. V7_0-branch) to go to the next version number and to include the string "PRE-RELEASE-UWCS".
+*:: =git checkout V7_0-branch=
+*:: Edit =src/condor_c++_util/condor_version.cpp=
+*:: Set the version string to: ="$CondorVersion: 7.0.4 " __DATE__ BUILDIDSTR " PRE-RELEASE-UWCS $";=
+*:: =git diff= (to verify the change before you commit it)...
+*:: =git commit -a -m "updated version string for 7.0.4"=
+*:: =git push origin V7_0-branch=
+
+1: Get ready to make a release branch for the manual. You should ensure that ALL of the required doc merges are done. Usually Karen (smoler@cs) takes care of this, but you should check with her to coordinate. If she's not around, there are usually 3 merges that need to happen for any development series release. For example, to release 7.1.1, assuming we've been updating the V7_0_3-branch of doc for stable series changes, you'd need to do the following before you could make a V7_1_1-branch of doc:
+*:: =V7_0_3-branch= into =V7_0-branch= (the current 7.0 manual)
+*:: =V7_1_0-branch= into =V7_1-branch= (the current 7.1 manual)
+*:: =V7_0-branch= into =V7_1-branch= (to get all the recent 7.0 changes into 7.1 as well)
+If you're doing a stable series release, you'd only need to do the first of those merges (=V7_0_3-branch= into =V7_0-branch=) and you'd be ready to create a =V7_0_4-branch= of the manual.
+
+1: Make a release branch for the manual. ASK KAREN FIRST! For example, if you're releasing 7.0.3:
+*:: =git clone /p/condor/repository/CONDOR_DOC.git=
+*:: =cd CONDOR_DOC=
+*:: =git branch V7_0_3-branch origin/V7_0-branch=
+*:: =git push origin V7_0_3-branch=
+
+1: On the main branch of the manual (*not* the newly created release branch, but for example, the regular V7_0-branch), update condor-macros.tex and Makefile to up the version number to the next version, and push those changes to CONDOR_DOC.git.
+
+1: Make sure the nightly build tags are being made on the release branch:
+*:: =cd /p/condor/home/tools/cvs-tools=
+*:: Edit =create_build_tag-input=
+*:: Uncomment and modify a section that defines a nightly build tag on the appropriate release branch. See the other examples in the file for details. There's also a very complete comment at the top of the =create_build_tag= script itself.
+*:: =cvs diff create_build_tag-input= (to verify the change before you commit it)...
+*:: =cvs commit -m "added nightly build tags for V6_X_Y-branch" create_build_tag-input=
+
+1: Watch the nightly builds the next morning to ensure everything is working fine. Common problems include:
+*:: Confusion with the proper branch to pull the manual from for the nightly build tag.
+
+1: If you'd like to fire off a build immediately, then read the {wiki: NmiBuild Building Condor with NMI} page. You'll need to start the build as cndrauto so follow the directions.
+
+That's it... you're done with the prep-work. Now, the real work begins...
+
+{subsection: Final Release Process}
+
 Yet to be imported...