*:: =git commit -a -m "updated version string for 7.0.4"=
*:: =git push origin V7_0-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: 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_SRC.git.
1: We’re modifying our process to start with an upgrade request ticket whose body includes specific issues to note for the release. Essentially, the idea is to send in the NMI ticket same new release announcement we are going to send to our user community. This way, the NMI admins act as a 'beta site' for the relevancy of our release announcement. If we have issues upgrading, we’ll update the ticket text so that that it become the email that is ultimately sent to users.
@@ -111,7 +111,7 @@
1: Verify the list of supported platforms in the manual. This generally means talking to Pete Keller. The list is in =doc/overview/overview.tex= under 'Availability'. Furthermore, the platform-specific notes in the manual =doc/platforms/*= should be verified and updated if there have been any changes.
1: Tag Build ID w/ release tag. For example, to create "V7_0_3" as opposed to "BUILD-V7_0_3-branch-2008-6-15":
-*:: (Assume clones of CONDOR_SRC.git, and CONDOR_DOC.git are present.)
+*:: (Assume a clone of CONDOR_SRC.git is present.)
*:: =cd CONDOR_SRC=
*:: =git tag V7_0_3 BUILD-V7_0_3-branch-2008-6-15=
*:: =git push origin V7_0_3= (This puts the V7_0_3 tag in the central CONDOR_SRC.git repo.)
@@ -191,8 +191,8 @@
1: Build the manual.
{code}
PATH=/s/gs/bin:$PATH
-git clone /p/condor/repository/CONDOR_DOC.git
-cd CONDOR_DOC
+git clone /p/condor/repository/CONDOR_SRC.git
+cd CONDOR_SRC
git checkout -b V7_0_3-branch origin/V7_0_3-branch
cd doc
make release
