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 to up the version number to the next version, and push those changes to CONDOR_SRC.git.
-1: We are 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 will update the ticket text so that that it become the email that is ultimately sent to users.
+1: We are 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 will update the ticket text so that that it become the email that is ultimately sent to users. Note this is only needed for development releases.
1: Make sure the nightly build tags are being made on the release branch:
*:: =cd /p/condor/home/tools/cvs-tools=
@@ -64,8 +64,7 @@
*:: =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: Watch the nightly builds the next morning to ensure everything is working fine.
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.
