Page History

Turn Off History

This is an attempt to enumerate all the steps necessary to release a new version of Condor, given a valid nightly build ID. It's currently a work-in-progress, but will hopefully converge on an authoritative list in the near future.

There are now two major parts of wrangling a release:

Each task is described in its own section. In general, the version history is a ton of work, so it's best to select two separate people, one to do the version history, one for wrangling everything else.

Making Sure the Version History Is Right

First, be sure to read the Version History Policy and FAQ. This spells out the policy for the version history and explains a big part of your task at release time: finding missing entries.

Of course, you can't finalize the version history until the code-freeze for the release and the source is tagged. So, in practice, you'll have to coordinate with the real release wrangler to make sure you'll looking at the right diff.

Once you've got the official release tag (or the build tag that's going to become the official tag), here's what you do:

  1. Check out a copy of the version history to verify: 
    git clone /p/condor/repository/CONDOR_DOC.git
cd CONDOR_DOC
git checkout -b V7_0_2-branch origin/V7_0_2-branch
    Inside doc, you'll need to edit version-history/X-Y.history.tex where X-Y matches the release series you're working from (e.g. 7-0).
  2. Run git log between the last release and the current release from the same series: 
    git log -p V7_0_1..V7_0_2 > 7.0.2-diff
    If the V7_0_2 tag doesn't exist yet, use the appropriate build tag, e.g. BUILD-V7_0_2-branch-2008-6-9.
  3. Go through the saved output (e.g. 7.0.2-diff) and make sure everything in there that should be documented has a corresponding entry in the version history.
  4. If you find parts of the diff that should be documented which are missing, make a list of the missing entries and who committed the changes.
  5. Once you've gone through the entire diff, email your list of missing entries to condor-team@cs.wisc.edu for public humiliation and so that people know how much they owe to the version history pizza fund (see the policy/FAQ). You can either add the missing entries yourself, or get the guilty parties to do it.

That's the whole task. However, give yourself at least a day to do it, since the diff can be huge and this is a time consuming process. Once you're done, notify the "real" release wrangler so they know when it's safe to publicly release the manual.

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)
  2. Release process given a valid build candidate

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.

  2. 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!

  3. 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.

  4. 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. 
      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
    • or, if you'd like to make the branch off of the V7_0-branch: 
      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
  5. 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

  6. 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

  7. 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.

  8. 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

  9. 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.

  10. 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

  11. 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.

  12. If you'd like to fire off a build immediately, then read the 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...

Final Release Process

Yet to be imported...