ViewVC Help
View File | Revision Log | Show Annotations | Root Listing
(Generate patch)

Comparing CM/release.howto (file contents):
Revision 1.3 by arta, Wed Dec 5 00:03:02 2007 UTC vs.
Revision 1.4 by arta, Sat Dec 8 00:02:52 2007 UTC

# Line 8 | Line 8 | Art's suggested release recipe:
9   3. Repeat step 2 for all machine types supported.
10   4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h.
11 + 4a. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the release notes (see below).  Commit.
12   5. From the machine used in step 2, create a tag for the new release.  cd to $JSOCROOT.  Run "cvs tag -c Ver_<MAJ>-<MIN> ."  Replace <MAJ> with the major version number and <MIN> with the minor version number.
13 + 5a. The NetDRMS release version number should also be incremented and tagged. From another machine, do "cvs checkout -AP DRMS".  Then cd to the root (JSOC). Then "find . -path '*CVS' -prune -o \( -type f -exec cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> {} \; \)"
14   6. Update the "Ver_LATEST" tag.  This tag always points to the latest release.  "cd $JSOCROOT; cvs rtag -r Ver_<MAJ>-<MIN> Ver_LATEST JSOC", where <MAJ> and <MIN> are the current release.
15   7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h.  The version macros should be of the form:
# Line 19 | Line 21 | The "X" and "-" denote that binaries wer
21   8. From the machine used in step 7, commit $JSOCROOT/base/libdrms/jsoc_version.h.  You might have to run "cvs update -A base/libdrms/jsoc_version.h" to clear the stick flag created when you first sync'd in step 2 (if you used the "-r" flag).
22   9. Ensure that the tag was successfully created and create actual release binaries (not just the binaries in your sandbox).  Login as the production user, checkout the tagged files (cvs checkout -r Ver_<MAJ>-<MIN> JSOC) and build on all machines supported.  
23   10. Update the "working release".  The source for these binaries lives in /home/jsoc/cvs/JSOC.  cd to /home/jsoc/cvs, and do "cvs checkout -r Ver_<MAJ>-<MIN> JSOC" and build on all machines supported.
24 < 11. Send instructions for using the new release to users.
24 > 12. Send instructions for using the new release to users.
26   ================================================================================
27   Example New Release Instructions
# Line 58 | Line 60 | the working release get updated.  WARNIN
60   since by the time you see them, another user may have edited them. Only the production
61   release is guaranteed to be stable and unchanged between releases.
63 < Updating to this release
64 < -----------------------
65 < Once you have a sandbox, you may want to update it to this release so that you
66 < get new functionality that is stable (the binaries build and run properly).  
67 < The general way of doing this is to run "cvs update -APd -r Ver_3-8" from $JSOCROOT.
68 < The "-r" flag tells cvs to ensure that all your local files have the versions that
69 < compose the 3.8 Release.  You would then need to run "make" from $JSOCROOT to
70 < build the binaries.  Alternatively, there is a script, $JSOCROOT/jsoc_update.csh
71 < that can be used to both update to the latest release and to build JSOC on all
72 < supported machines.  To do this, run $JSOCROOT/jsoc_update.csh -R.  The "-R" flag
73 < tells cvs to update to the latest release before building on the supported
74 < machine types.  This script generates log files for each machine type:
75 < $JSOCROOT/make_jsoc_linux_X86_64.log and $JSOCROOT/make_jsoc_linux_ia32.log.
76 < You should examine these logs to look for errors.  Before updating to the release
77 < with either of these alternatives, ensure that somewhere in your setup
76 < "source $HOME/.setJSOCenv" exists.  
77 <
78 < If You Don't Have a Sandbox
79 < ---------------------------
80 < You need a cvs "sandbox" to contain your view of a JSOC release:
81 < (There is no need to do this unless you're going to be a jsoc developer.)
82 <
83 < Set the env variables:
84 <
85 < CVS_RSH=ssh
86 <
87 < Make a cvs dir and do:
88 < > cd /home/you/cvs
89 < > cvs checkout JSOC
90 <
91 < This will copy the LATEST version of all cvs depot files to /home/you/cvs/JSOC.
92 < These are not guaranteed to be stable.  This is something you may want to do if
93 < you are a developer, perhaps you are fixing a broken build.  If instead you want
94 < this stable release, then substitute "cvs checkout -r Ver_3-8 JSOC" for the above
95 < "cvs checkout JSOC" command.
96 <
97 < You would then make changes to the checked-out files, and commit them back to the
98 < depot with the "cvs commit files..." command.  Only after running this command
99 < can users "see" your changes.  To "see" your changes, a user would need to update
100 < their sandbox with the latest changes to the depot ("cd $JSOCROOT; cvs update -APd" )
63 > Obtaining the Release
64 > ---------------------
65 > To update your working directory to this release, or to check-out this release anew,
66 > please visit Please keep in mind that
67 > users may have modified files since the release was created, so use of the
68 > scripts documented in the web page may result in a working directory whose
69 > content is not identical to the release.  If updating, you can supply
70 > the flag "-R" to the jsoc_update.csh and jsoc_sync.csh scripts to download the
71 > latest release.  This will ensure that your working directory has the exact, latest
72 > release versions of the files (eg., jsoc_sync.csh -R). If checking-out,
73 > you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
74 > to achieve the analogous result, but for a fresh checkout.  WARNING: if you use
75 > the "-R" or "-r" flags, please use only jsoc_update.csh or jsoc_sync.csh to update
76 > your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
77 > "sticky flag" being set.  jsoc_update.csh and jsoc_sync.csh clear this sticky flag.
79   Additional Info
80   ---------------

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines