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:
+1: For old-batlab, 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.
+1: Watch the nightly builds the next morning to ensure everything is working fine. This step does not apply to the new batlab; it has per-commit builds rather than nightly builds.
1: If you'd like to fire off a build immediately, then read the {wiki: NmiBuild Building HTCondor with NMI} page. You'll need to start the build as cndrauto so follow the directions.
@@ -91,14 +91,13 @@
current release wrangler and have just pinned 7.0.0. The release wrangler
for 7.0.1 will unpin the 7.0.0 release.
-1: Make sure we've got a win32 build and releasable package (at this point, the nightly windows builds still don't provide packaging, so this remains a manual step).
+1: Make sure we've got a win32 build and releasable package (at this point, the nightly windows builds provide a MSI automatically).
*:: Verify the contents of the .ZIP file
-*::: Check the layout of the file (currently there is an extra directory)
+*::: Check the layout of the file (some iterations had an extra directory)
*::: Check to see that condor_mail.exe is not missing.
*::: Check for debug binaries {code}link /dump /imports bin\* | grep -e "MSVC.*D"{endcode} If any of the HTCondor programs or dlls are linked with the debug c-runtime, there will be output. Otherwise there will not be.
-*:: Either TJ can create the Windows MSI
-*:: Rename the zip and MSI file to include the platform string
-*:: Test the MSI installer.
+*:: If ther is no MSI from batlab, TJ can create the Windows MSI
+*:: Test the MSI installer. vm-crane.chtc.wisc.edu can be used for this.
1: Deploy binaries onto production pool, start the "N-day" counter.
Stable releases go onto the CS Dept. pool. Upgrading this pool is a complicated process in itself, which is documented on the {link: http://www.cs.wisc.edu/condor/developers/pool-update.html Upgrading the UW CS Pool} page. Developement releases go onto the {quote:BaTLab} and CHTC pools. Talk to the infrastructure team to arrange upgrading these pools.
