Page History
- 2020-Jul-16 12:30 johnkn
- 2014-Jul-02 13:21 adesmet
- 2014-Jul-02 13:20 adesmet
- 2013-Aug-16 16:49 matyas
- 2013-May-20 17:53 johnkn
- 2013-Mar-28 15:08 johnkn
- 2013-Mar-28 15:04 johnkn
- 2013-Feb-26 13:21 adesmet
- 2013-Jan-16 16:48 johnkn
- 2013-Jan-16 09:28 johnkn
- 2012-Dec-18 11:02 johnkn
- 2012-Dec-11 15:24 johnkn
- 2012-Dec-06 14:01 bgietzel
- 2012-Nov-16 13:59 adesmet
- 2012-Nov-13 17:02 adesmet
- 2012-Nov-13 16:40 adesmet
- 2012-Oct-24 17:21 johnkn
- 2012-Aug-22 15:50 kronenfe
- 2012-Aug-15 15:11 kronenfe
- 2012-Aug-15 09:49 kronenfe
- 2012-Aug-14 16:36 kronenfe
- 2012-Jul-30 13:39 adesmet
- 2012-Jun-18 11:13 kronenfe
- 2012-May-10 17:36 gthain
- 2012-May-10 11:03 gthain
- 2012-May-09 12:22 kronenfe
- 2012-Mar-28 14:15 kronenfe
- 2012-Feb-28 14:36 gthain
- 2012-Jan-11 09:36 gthain
- 2011-Dec-28 12:31 gthain
- 2011-Oct-28 09:57 johnkn
- 2011-Oct-28 09:52 johnkn
- 2011-Oct-24 09:12 gthain
- 2011-Oct-20 14:04 johnkn
- 2011-Oct-16 21:36 gthain
- 2011-Oct-16 21:35 gthain
- 2011-Oct-12 10:50 jfrey
- 2011-Oct-11 16:33 kronenfe
- 2011-Sep-14 10:56 kronenfe
- 2011-Sep-13 10:12 gthain
- 2011-Sep-12 15:56 gthain
- 2011-Sep-09 08:38 gthain
- 2011-Aug-23 22:34 gthain
- 2011-Aug-18 10:45 gthain
- 2011-Aug-09 07:32 gthain
- 2011-Aug-01 11:09 gthain
- 2011-Aug-01 10:41 kronenfe
- 2011-Aug-01 10:18 kronenfe
- 2011-Aug-01 10:15 kronenfe
- 2011-Jul-29 14:32 kronenfe
- 2011-Jul-27 14:54 bgietzel
- 2011-Jul-18 12:30 johnkn
- 2011-Jul-08 15:17 johnkn
- 2011-Apr-18 14:46 gthain
- 2011-Mar-28 13:07 johnkn
- 2011-Mar-28 12:36 kronenfe
- 2011-Mar-23 20:31 kooburat
- 2011-Mar-22 12:29 nleroy
- 2011-Feb-02 14:01 nleroy
- 2011-Jan-27 12:43 kronenfe
- 2011-Jan-27 11:35 kronenfe
- 2011-Jan-27 10:55 danb
- 2011-Jan-05 12:21 gthain
- 2010-Nov-04 14:06 psilord
- 2010-Oct-25 18:34 jfrey
- 2010-Oct-21 15:51 adesmet
- 2010-Oct-21 15:50 adesmet
- 2010-Oct-21 15:49 adesmet
- 2010-Oct-21 15:38 adesmet
- 2010-Oct-21 15:35 adesmet
- 2010-Oct-21 15:31 adesmet
- 2010-Oct-21 15:24 adesmet
- 2010-Oct-21 15:12 adesmet
- 2010-Oct-21 15:00 adesmet
- 2010-Oct-20 17:11 adesmet
- 2010-Oct-19 10:27 johnkn
- 2010-Oct-18 15:45 adesmet
- 2010-Oct-14 17:07 adesmet
- 2010-Aug-23 18:30 adesmet
- 2010-Aug-19 17:18 gthain
- 2010-Aug-16 12:51 gthain
- 2010-Aug-12 13:31 gthain
- 2010-Jul-02 12:05 cweiss
- 2010-Jun-29 11:57 kooburat
- 2010-Jun-16 12:47 nleroy
- 2010-Jun-15 14:53 nleroy
- 2010-Jun-15 14:48 nleroy
- 2010-Jun-10 13:42 adesmet
- 2010-May-20 18:43 kooburat
- 2010-May-20 18:29 kooburat
- 2010-Apr-23 10:18 psilord
- 2010-Apr-06 11:41 adesmet
- 2010-Mar-29 15:10 psilord
- 2010-Mar-03 14:30 jfrey
- 2010-Mar-03 14:28 jfrey
- 2010-Mar-03 14:27 jfrey
- 2010-Mar-03 12:00 matyas
- 2010-Mar-03 11:42 jfrey
- 2010-Feb-26 00:37 jfrey
- 2010-Feb-19 16:11 tannenba
- 2010-Feb-12 10:55 matyas
- 2010-Jan-04 15:10 adesmet
- 2009-Dec-21 09:57 danb
- 2009-Nov-10 16:49 adesmet
- 2009-Nov-09 18:59 adesmet
- 2009-Nov-09 17:33 adesmet
- 2009-Nov-09 17:27 adesmet
- 2009-Nov-09 16:28 adesmet
- 2009-Nov-09 15:44 adesmet
- 2009-Nov-09 15:41 adesmet
- 2009-Nov-09 15:39 adesmet
- 2009-Nov-06 14:31 nleroy
- 2009-Nov-06 14:26 adesmet
- 2009-Nov-05 15:15 adesmet
- 2009-Nov-05 13:40 adesmet
- 2009-Nov-05 13:06 adesmet
- 2009-Nov-05 13:04 adesmet
- 2009-Nov-05 12:46 adesmet
- 2009-Oct-29 17:34 adesmet
- 2009-Sep-16 14:01 psilord
- 2009-Jun-22 00:43 danb
- 2009-May-13 14:53 jfrey
- 2009-May-13 11:38 jfrey
- 2009-May-13 10:58 jfrey
- 2009-May-13 10:50 jfrey
- 2009-May-13 10:48 jfrey
- 2009-May-13 10:41 jfrey
- 2009-May-13 10:28 jfrey
- 2009-May-12 18:14 jfrey
- 2009-May-12 18:09 jfrey
- 2009-May-12 17:51 jfrey
There are now two major parts of wrangling a release:
- Making sure the version history is right
- Everything else
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're 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:
- 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
version-history/X-Y.history.tex
whereX-Y
matches the release series you're working from (e.g.7-0
). - 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
V7_0_2
tag doesn't exist yet, use the appropriate build tag, e.g.BUILD-V7_0_2-branch-2008-6-9
. - 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. - 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.
- 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:
- Preliminary work to freeze the code, make a release branch, etc. (this can take a few days, so start early)
- Release process given a valid build candidate
Preliminary Work
- 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.
- 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! - 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. - 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 clone 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
- 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
- either way, be sure to update GitBranchDescriptions to document the new branch
- The preferred method for making a release branch is from a known good build tag on NMI.
- 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
- 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
- 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. If you're doing a stable series release, you'd only need to do the first of those merges (
V7_0_3-branch
intoV7_0-branch
) and you'd be ready to create aV7_0_4-branch
of the manual.V7_0_3-branch
intoV7_0-branch
(the current 7.0 manual)V7_1_0-branch
intoV7_1-branch
(the current 7.1 manual)V7_0-branch
intoV7_1-branch
(to get all the recent 7.0 changes into 7.1 as well)
- 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
- 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.
- 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
- 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.
- 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
- Settle on a build ID candidate that can build on all platforms
- Perform the ManualRegressionTests, possibly assigning some to various staff members.
- On nmi-s006, pin the build for 120 days using
/nmi/bin/nmi_pin
:$ nmi_pin --days=120 --force <runid>
- 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).
- Definitive pass-thru of test results, by platform. Need a list by platform saying "good" or "bad".
- Deploy binaries onto production pool, start the "N-day" counter.
This is a complicated process in itself, which is documented on the Upgrading the UW CS Pool page.
- 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)
- RUST-watcher must be diligent about looking for "bad things", bug reports from our users, etc.
- The Version History et all in the manual needs to be verified that it is all up to date. See the section on updating the version history above for details.
- The list of supported platforms in the manual needs to be verified that it is all up to date. This generally means talking to Pete Keller. The list is in
doc/overview/overview.tex
under 'Availability'. Furthermore, the platform-specific notes in the manualdoc/platforms/*
should be verified and updated if there have been any changes. - 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.)
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.)- Note: Push the TAG name, not the branch name.
- update GitBranchDescriptions to document the new branch
- Name of the tag and date the tag was created.
- The branch the tag was created on.
- The official version string included in that release.
- The original build tag that the release tag was created from. This last point is very important, since it contains the actual date the release's codebase came from, not just the date the release tag "alias" was created. This is important for date-based comparisons in git, for example.
- For example, here's the 6.9.5 tag's entry:
11/28/07 V6_9_5 The offical tag for 6.9.5, from the V6_9_5-branch. Version string: $CondorVersion: 6.9.5 Nov 28 2007 BuildID: 65347 $ Original build tag: BUILD-V6_9_5-branch-2007-11-28
cd ../CONDOR_DOC
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_DOC.git repo.)
- Pre-release binary tarballs to the web.
The binaries are not available to the public until they've been pushed to the mirrors (see step 14). However, they still need to be placed into AFS for the download system to find. If the version of Condor is
X.Y.Z
, then place the binary releases of Condor for the various available architectures into/p/condor/public/binaries/vX.Y/X.Y.Z
. Note that for any particular architecture,unstripped
binaries should not be released to the web if there is a correspondingcondordebugsyms
tarball. And with 7.5.x and above, static binaries should not be released.- UNIX: Mostly this involves copying everything off of nmi-s006 and into /p/condor/public/binaries/...
- Option 1: Use nmi_crowbar
- Find a machine with lots of space in /scratch or /scratch.1. This process requires about 35GB, as of November 2009. chopin.cs.wisc.edu's /scratch.1 is a good choice.
- Pull down the binaries. This will take about an hour, more if you decide to set --into to point into AFS.
nmi_crowbar --runid=193173 --download --flatten --unpack-style=release \ --scratch=/scratch.1/adesmet --into=/scratch.1/adesmet/7.4.0-binaries
- Delete the checksum files, we don't currently use them
rm *.md5 *.sha1
- Delete the pieces of a Windows install left around. You need to do this because the Windows tarballs are packaged differently and nmi_crowbar doesn't yet special case for it.
rm -rf bin/ etc/ examples/ hdfs/ include/ lib/ logs/ sql/ src/ testbin/
- For each condordebugsyms-* file, delete any corresponding * -unstripped.tar.gz". That is, for any given platform there should be a * -unstripped.tar.gz or a condordebugsyms-*.
- Move everything into place. This could take thirty minutes or so.
mv * /p/condor/public/binaries/stable/7.4/7.4.0/
- Option 2: Use Nick's shiny "nmi-extract-results" script, which lives in tools/nmi-interaction. It's also in ~nleroy/bin on nmi-s006.
The script writes to ./cache and ./public -- and will create these directories if they don't already exist. The cache is to maintain a list of things that it's already extracted from, so if you run it again, it won't do unnessesary work.
I included help below because the Python on nmi-s006 is old & crusty, and --help doesn't work properly.nmi-extract-results -h Usage: nmi-extract-results: [options] Options: --version show program's version number and exit -h, --help show this help message and exit -d DATE, --date=DATE Set date yyyy/mm/dd|yy/mm/dd|mm/dd <2008/11/12> -r RUNID, --runid=RUNID Specify runid (slow); example: 113473 -g GID, --gid=GID Specify GID; example: 1225823210_6802 --condor-version=VERSION Specify condor version (i.e. '7.1.4') --find Exit after locating the run directory -n, --no-exec Disable execution
- login to nmi-s006
- Get the GID or the (RunID and date of the build) of the build you want.
- Run the extractor in one of the following forms:
- This version takes a GID
$ nmi-extract-results --gid <GID>
- This version takes a runid and looks for builds within +/- 24 hours of today that match the passed in RID
$ nmi-extract-results --runid <RunID>
- This version takes an runid and looks for builds with +/- 24 hours of the specified date
$ nmi-extract-results --runid <RunID> --date <date>
- This version takes a GID
- The --runid search modes aren't all that painful at all, it generally finds the matching RunID in well less than a minute, so it's much better than the "run find by hand" method, which is painful.
- If it succeeds in finding the build, it will then extract all of the relevant binaries into ./public/v7.1.2 (well, actually, the correct name). When it's done, you should have everything you need in that directory, including the condor_src and windows tarballs (note, however, that we, as of yet, still need to have Ben build the ZIP and MSI files).
- Copy the files back to one of the CSL machines; I try to use nation or one of the less used machines, especially if I'm copying directly into AFS, otherwise it loads them down badly (AFS just doesn't handle it well at all).
$ cd public/v7.1.4 $ rsync -av --rsh=ssh * nation:/p/condor/public/binaries/v7.1/7.1.4
- Option 3: Do it by hand:
- for a given build's GID, run the following on nmi-s006:
GID=cndrauto_nmi-s006.cs.wisc.edu_1167884128_28240 RELEASE=6.8.3 cd /space/tmp mkdir release-$RELEASE cd release-$RELEASE find /nmi/run/cndrauto/*/*/$GID/userdir -type f -name results.tar.gz | grep -v '/common/' | grep -v '/nmi:x86_winnt_5.1/' | xargs -n1 tar xvzf cp /nmi/run/cndrauto/*/*/$GID/userdir/nmi\:x86_winnt_5.1/release.tar.gz condor-$RELEASE-winnt50-x86.tar.gz tar zxvf /nmi/run/cndrauto/*/*/$GID/userdir/common/results.tar.gz condor-$RELEASE.tar.gz
- Get some coffee, it'll be a while.
- On a CSL machine:
RELEASE_MAJOR=6.8 RELEASE=6.8.3 cd /p/condor/public/binaries/v$RELEASE_MAJOR mkdir $RELEASE cd $RELEASE rsync -v --progress --rsh=ssh nmi-s006:/space/tmp/release-$RELEASE/public/v$RELEASE_MAJOR/'*' ./ ls | grep -v unstripped | xargs --replace mv '{}' ../
- (You can also use "
scp nmi-s006:/space/tmp/release-$RELEASE/public/v$RELEASE_MAJOR/'*' ./
" to copy the binaries over. rsync provides the advantage that you can re-run it over and over again if your transfer is interrupted and you won't re-copy what you already have.)
- for a given build's GID, run the following on nmi-s006:
- Option 3: Derek has a script to search through a given NMI rundir and move everything we need. The script lives in the nmi_tools directory in git, and is called
move_to_afs
. Beware that this script will eat up around 8 gigabytes while it runs. It's also old and crusty and should be avoided.
- Option 1: Use nmi_crowbar
- WINDOWS: With <Current version +1> hopefully Windows packages will be automatic. Until that's working, ask Todd Tannenbaum or Ziliang Guo to manually create the packages.
- UNIX: Mostly this involves copying everything off of nmi-s006 and into /p/condor/public/binaries/...
- XXX This step needs a refinement in the script intellect. XXX
Create matching glidein tarballs, and install in /p/condor/public/html/glidein/binaries. This process is handled by running the following script, replacing 7.1.1 with the version you are releasing:make_glidein_tarballs 7.1.1
- Release source tarball. The source tarball is created every night as part of the nightly builds. Nick's
nmi-extract-results
script will extract it along will all of the binary tarballs. Otherwise, you can extract it yourself. If you look in therundir
of a given NMI runid, you should see a tarball inuserdir/common
namedresults.tar.gz
, which contains the source tarball. Extract it like so:tar zxvf results.tar.gz condor-X.Y.Z.tar.gz
/p/condor/public/cgi-bin/source/tarballs
, and it should be named "condor_src.VX_Y_Z.tar.gz
". You must run/p/condor/public/cgi-bin/source/make_links.pl
after copying the the source tarball into place. The source should also be placed in/p/condor/public/binaries/vX.Y/X.Y.Z
using the name "condor_src-X.Y.Z-all-all.tar.gz
". - Tell the new download system about the new binaries.
- All of the programs listed here take --help options, and the are all discussed to some extent in /p/condor/downloads/doc/operation.txt .
- These tools require Python version 2.5. The /s/std/bin/python on Centos 4.5 is 2.4.1, and these scripts won't run with it. If that's the case, add /s/python-2.5/bin/ to the front of your PATH. You can detect the version of the python that you're running by:
$ which python /s/std/bin/python $ python -V # Note that this is a capital "V". Python 2.4.1 $ /s/std/bin/python -V Python 2.4.1 $ /s/python-2.5/bin/python -V Python 2.5 $ export PATH=/s/python-2.5/bin:$PATH $ rehash $ which python /s/python-2.5/bin/python $ python -V Python 2.5
- For more complete documentation on the download tools, look at /p/condor/downloads/doc/operation.txt
- Add a version to the new download "database". In this case, we'll install version 7.0.2, and we'll copy the release information from 7.0.1, except for the release date. Then, we'll edit the 7.0.1 description to reflect that it's no longer the most recent. Finally, we'll blow away 7.0.0 entirely. These steps are required. For all of the below commands, I'm going to assume that you've added
/p/condor/downloads/bin
to your PATH.- List the current versions:
$ download-versions print
- Create the 7.0.2 version:
$ download-versions --copy 7.0.1 --date 2008/06/10 add 7.0.2
- Update the 7.0.1 description:
$ download-versions update --description "Recent Stable Release" 7.0.1
- Delete the 7.0.0 release. The first step "download-delete" will delete the files maintained by the download subsystem. The second step "download-versions delete" will delete the version from the version database. So, do the following:
$ download-delete 7.0.0
- NRL: Don't do this, at least for now....
$ download-versions delete 7.0.0
- List the current versions:
- If this is a new series, you will need to edit /p/condor/downloads/etc/downloads.conf and add a few lines. Search for the previous series and follow its example. In particular, as a "[release 7.4] section, using a previous release as a template. Also, for each "[mirror SOMETHING]" section, add a release_7_4 entry, using previous releases as a template.
- Install the binaries into the new download system. This step is required.
$ download-install -v --mode symlink 7.0.2 /p/condor/public/binaries/v7.0/7.0.2
- Here's how you would create a disabled 7.1.3 version, install binaries for it, and then enable it later, changing the date to match the actual release
$ download-versions add 7.1.3 --copy 7.1.2 --date +3 --descr "Latest Developer Release" --disable ... $ download-install -v --mode symlink 7.1.3 /p/condor/public/binaries/v7.1/7.1.3 ... $ download-versions up 7.1.3 --enable --today
- Push the new binaries out to the local mirror (parrot). If we didn't specify the "--mirror parrot", it'd push to all mirrors, including INFN, and that takes quite a while. A push to parrot usually takes on the order of 50 minutes or so. The binaries will be automatically pushed to all mirrors every AM, but this allows us to get it to one mirror at least.
$ download-push -v --mode real --mirror parrot 7.0.2
- Generate symlinks to the binaries & push them out to the local mirror. This is also done by cron, twice per hour, so, if you didn't do this step, it'd get done for you. However, it only takes a few minutes, so I included it here.
$ download-gen-symlinks -v --mirror parrot
- Verify that you can actually download a binary, unpack it, run condor_version and get the expected output. Also download the source and one other binary.
- Is this a new series release (x.x.0)? There are some additional details:
- Add a new license agreement. This is usually just copying the old license to a new name.
- Check out the condor-web CVS module.
- cd condor-web/src/downloads
- cp v7.3.license.html v7.4.license.html
- edit v7.4.license.html to change the Condor version numebr.
- cvs add v7.4.license.html
- cvs ci
- cd ../..
- ./generate_html src
- Update the download system's information. Note that the warnings above download-versions being incompatible with the standard Python install stands; make sure you use a more recent Python.
download-versions update --lic=http://parrot.cs.wisc.edu/v7.4.license.html \ --inst=http://www.cs.wisc.edu/condor/manual/v7.4/3_2Installation.html 7.4.0
- The download log files must exist; the download scripts won't create them if they don't.
cd /p/condor/public/license touch licensers-v7.4 problem-v7.4 sendfile-v7.4
- Add a new license agreement. This is usually just copying the old license to a new name.
- Set the release date (the date the new version hit the Condor web site) in the Condor Manual's Version History item devoted to identifying the release date. OR, tell Karen exactly what date to use, and she'll do it for you. (#1236)
- Release the manual. Continuing the V7_0_3 example...
- build the manual
git clone /p/condor/repository/CONDOR_DOC.git cd CONDOR_DOC git checkout -b V7_0_3-branch origin/V7_0_3-branch 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 v7.0 ln -s v7.0.3 v7.0
- build the manual
- 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 add an announcement 'Whats New?')- Here is a sample announcement:
{ date => 'January 22, 2008', title => 'Condor 7.0.0 released!', news => <<ENDNEWS The Condor Team is pleased to announce the release of Condor 7.0.0. This first release in a new stable series includes all new features added in the 6.9 development series. See the <a href="http://www.cs.wisc.edu/condor/manual/v7.0/8_3Stable_Release.html#sec:New-7-0-0">Version History</a> for a complete list of changes. Condor 7.0.0 binaries and source code are available from <a href="http://www.cs.wisc.edu/condor/downloads/">our Downloads page.</a> ENDNEWS },
- Here is a sample announcement:
- edit
src/downloads/index.html
(to fix the release-specific text on the main downloads page) - touch
src/index.html
(so the main page updates with the version information from thedownloads/index.html
page) - touch
src/manual/index.html
(so the manual links update with the version information from thedownloads/index.html
page) - NOTE: if you're doing the first release of a new release series, you'll also need to edit:
src/index.html
to:- change the "The Condor Manual:" list of links (chances are good you'll want to remove something older when you add the new one -- we'll never want that list to be longer than 3 links).
src/developers/index.html
to add the new series to the "Manuals and Other Documentation" list.- edit
src/manual/index.html
(to update which versions of each branch/release series are 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).
- Archive release products to DVD. Get recordable DVDs and DVD slipcovers from Ken. Drop off the finished DVD with Pete, who will store it in a box in his filing cabinet. Include the following (the archiving directions include these):
- Binary tarballs. This includes archiving the unstripped binaries.
- Matching glidein tarballs. Get these from
/p/condor/public/binaries/glidein
.$ ssh tonic "cd /p/condor/public/binaries; tar cf - glidein/7.1.3" | tar xvfpS -
- Source tarball.
- Manual: tarball of HTML tree, and
ref.pdf
. The HTML files are in/p/condor/public/html/manual
. Do something like this:$ ssh tonic "cd /p/condor/public; tar cf - html/manual/v7.1.3" | tar xvfpS -
- Stash the condor repository onto nmi-s006 by doing something like:
$ ssh nmi-s006 $ cd /scratch/condor_stash $ sudo condor-auto ./stash_condor -v V7_4_1
- Send email to condor-world and condor-users. Here is a sample announcement:
Hello, The Condor Team is pleased to announce the release of Condor 7.0.0. This first release in a new stable series includes all new features added in the 6.9 development series. See the Version History for a complete list of changes. Condor 7.0.0 binaries and source code are available from our Downloads page. Version History: http://www.cs.wisc.edu/condor/manual/v7.0/8_3Stable_Release.html#sec:New-7-0-0 Downloads Page: http://www.cs.wisc.edu/condor/downloads/ Thank you for your interest in Condor! - The Condor Team
- Close out all tickets fixed by this release.
- Update the Condor wikipedia page to indicate the current stable release.
- Stop building the branch nightly:
cd /p/condor/home/tools/cvs-tools
- Edit
create_build_tag-input
- Delete the section that defined the nightly build tag for this branch.
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