THE OMEN

Condor-6.6.6 Release Punch-List

1. Settle on a build ID candidate that can build on all platforms
   
   DONE (Build ID: 357 on imola.cs.wisc.edu)
    
2. 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).
   
   DONE
    
3. Definitive pass-thru of test results, by platform. Need a list by platform saying "good" or "bad".
   DONE
   
    

   PASSED	FAILED
   aix-52 dux-51 irix-65 linux-alpha-rh72 linux-ia64-rh72 linux-ia64-sles8 linux-x86-rh72 linux-x86-rh80 linux-x86-rh90 macosx-102 solaris-sparc-8 solaris-sparc-9	dux-40f hpux-1020 solaris-sparc-7

    

4. Deploy binaries onto production pool, start the "N-day" counter
   • N >= 1 for a development series release
   • N >= 3 for a bug fix release in a stable series (X.Y.>0)
   • N >= 28 for a new stable series (X.Y.0)
     
     DONE: First Deploy: July, 23, 2004
                   Second Deploy: July 27, 2004
      
5. RUST-watcher must be diligent about looking for "bad things", bug reports from our users, etc.
   
   DONE: Nick & Parag
    
6. The Version History et all in the manual needs to be verified that it is all up to date (i.e. check w/ Bonsai, update available platforms, etc).
   
   Nick
    
7. Tag Build ID w/ release tag. For example, to create "V6_6_6" as opposed to "BUILD-V6_6-branch-2004-5-3":
   • cvs rtag -r BUILD-V6_6_6-candidate-2004-7-26 V6_6_6 V6_6_ALL
   • cvs rtag -r BUILD-V6_6_6-candidate-2004-7-26 V6_6_6 V6_6_6_EXT
   • cvs co -r V6_6-branch src/CVS_Tags
   • edit src/CVS_Tags to document the new tag
   • cvs commit src/CVS_Tags
     
     DONE: Derek
      
8. Update src/condor_c++_util/condor_version.C on the main-line development branch (e.g. V6_6-branch) to go to the next version number and to include the string "PRE-RELEASE-UWCS".
   
   DONE: Parag
    
9. Create the version-specific externals module for the next version (e.g. "V6_6_6_EXT"), and move the branch-specific external module to point to this new version.
   • cvs co CVSROOT
   • edit CVSROOT/modules
     • as soon as we release a given version (V6_X_Y, e.g. V6_6_6), the next version (V6_X_Y+1, V6_6_7) will always use the same externals. so at this point, all you have to do is add something like this to the section on externals:
       # Externals needed for V6_6_7 (same as V6_6_6)
       V6_6_7_EXT -a V6_6_6_EXT
     • Move the V6_X_EXT module to point to the new version:
       V6_6_EXT -a V6_6_7_EXT
     cvs commit CVSROOT/modules
     
     DONE: Derek/Parag
      
10. Make a release branch for the manual. For example, if you're releasing 6.6.6:
    • cvs co -r V6_6-branch doc
    • cvs tag V6_6_6-root doc
    • cvs tag -b V6_6_6-branch doc
    • edit doc/CVS_Tags (to document these two new tags in the tag file on the parent branch (V6_6-branch, in this case).
    • cvs commit doc/CVS_Tags
      
      ON HOLD: Nick
       
11. On the main branch of the manual (*not* the newly created release branch, but for example, the regular V6_6-branch), update condor_macros.tex and Makefile to up the version number to the next version, and commit those changes to CVS.
    
    ON HOLD: Nick
     
12. Release binary tarballs to the web. Once things are in /p/condor/public/binaries/vX.Y, they are visible on the downloads page. If you put everything in a subdirectory (for example, /p/condor/public/binaries/v6.6/v6.6.5), they won't be visible until you're ready and move them, so that's probably the best place to put things as you're copying them onto AFS.
    • UNIX: Mostly this involves copying everything off of imola and into /p/condor/public/binaries/... Derek has a script to search through /home/build/[ID] on imola to move everything we need, so he should either make that script more accessible to the rest of the team or should be responsible for taking care of this step.
    • WINDOWS: Since Colin has to manually create this package, he usually just copies it into AFS directly.
      
      DONE: Parag
       
13. Release source tarball. The source tarball is created every night as part of the nightly builds. For now, it lives on imola in /wspaces/bt_test/nmi_build/[build_id]/CVSSRCSCONDOR/CONDOR/condor[version].tar Furthermore, the resulting tarball isn't really what we need. So, perhaps it's smarter to just use Todd's spiffy new script by entering on any lab-supported RedHat box: "/p/condor/home/tools/cvs-tools/create_src_release 6.X.Y" (NOTE: for this to work, the official V6_X_Y tag *MUST* already exist). The final source tarball should be placed in /p/condor/public/cgi-bin/source/tarballs, and it should be named "condor_src.V6_X_Y.tar.gz".
    
    DONE: Derek
     
14. Release the manual. Continuing the V6_6_6 example...
    • cvs co -r V6_6_6-branch doc
    • cd doc
    • make release
    • move the symlink in /p/condor/public/html/manual for whatever release series you're changing to point at the new version.
      • cd /p/condor/public/html/manual
      • rm v6.6
      • ln -s v6.6.6 v6.6
    • fix the HTML on the web regarding the manual (more on this soon)
      
      Nick
       
15. Update the web HTML regarding this release
    • cvs -d /p/condor/repository/HTML co condor-web
    • cd condor-web
    • edit src/lib/news.mas (to update 'Whats New?')
    • edit src/downloads/index.html (to fix the release-specific text on the main downloads page)
    • edit src/manual/index.html (to update the current manual)
    • cvs commit (all of your changes in condor-web)
    • ./generate_html src (to update the HTML on the web with your changes).
      
      Nate
       
16. Update the Italian mirror site (for now, just ask Nate to do it).
    
    NOT NEEDED: AUTOMATICALLY SYNCHED EVERY NIGHT
     
17. Send email to condor-world and condor-users.
    
    Erik