(file) Return to release.howto CVS log (file) (dir) Up to [Development] / JSOC / CM

Diff for /JSOC/CM/release.howto between version 1.3 and 1.12

version 1.3, 2007/12/05 00:03:02 version 1.12, 2009/07/29 21:25:44
Line 1 
Line 1 
 Art's suggested release recipe: Art's suggested release recipe:
  
 1. Notify users (jsoc_dev@sun.stanford.edu) that a new release will be built.  Allow users time to submit changes they want in the new release.  This includes changes made by the CM that have not been committed.  1. Notify users (jsoc_dev@sun.stanford.edu) that a new release will be
 2. From a cluster-node (eg., n00), perform a clean sync to head as a non-Production user (cvs checkout -r HEAD JSOC).  The -r rev option is sticky, which means that if you used -r Ver_3-2 on a previous checkout, that "cvs checkout JSOC" will check out Ver_3-2.  Use "-r HEAD" to force the use of the head revision. Update $JSOCROOT/base/jsoc_version.h to the latest release version and build again (make clean, make universe).  The version macros should be of the form:  built.  Allow users time to submit changes they want in the new
   release.  This includes changes made by the CM that have not been
   committed.
   
   2. From a cluster-node (eg., n00), perform a clean sync to
   head as a non-Production user (cvs checkout -r HEAD JSOC).  The -r rev
   option is sticky, which means that if you used -r Ver_3-2 on a
   previous checkout, that "cvs checkout JSOC" will check out Ver_3-2.
   Use "-r HEAD" to force the use of the head revision.
   
   3.Update $JSOCROOT/base/jsoc_version.h to the latest release version
   and build again (make clean, make universe).  The version macros
   should be of the form:
  
 #define jsoc_version "V3R5" #define jsoc_version "V3R5"
 #define jsoc_vers_num (305) #define jsoc_vers_num (305)
  
 3. Repeat step 2 for all machine types supported.  4. From the machine used in step 2, commit $JSOCROOT/base/jsoc_version.h.
 4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h.  
 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.  5. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the
 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.  release notes (see below).  Commit.
 7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h.  The version macros should be of the form:  
   6. From the machine used in step 2, create a tag for the new release.
     a. cd $JSOCROOT
     b. cvs tag -c Ver_<MAJ>-<MIN> . (Replace <MAJ>
   with the major version number and <MIN> with the minor version number.)
     c. cvs tag -d Ver_LATEST .
     d. cvs tag -c Ver_LATEST .
   
   7. The NetDRMS release version number should also be incremented and
   tagged:
     a. cd /tmp
     b. cvs checkout NETDRMSONLY (head version of netdrms-only files)
     c. cd JSOC
     d. cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> .
     e. cvs tag -d Ver_DRMSLATEST .
     f. cvs tag -c Ver_DRMSLATEST .
     g. cd /tmp
     h. cvs checkout -r Ver_<MAJ>-<MIN> CORE
     i. cd JSOC
     j. cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> . (minus excluded files)
     k. cvs tag -d Ver_DRMSLATEST .
     l. cvs tag -c Ver_DRMSLATEST . (minus excluded files)
   
   8. Now you must build all release executables with the release jsoc
   version numbers in place ("V3R5" and "305" in this example). Ensure
   that the tag was successfully created and create actual release
   binaries (not just the binaries in your sandbox).  Login as the 'jsoc'
   user, cd to /home/jsoc/cvs, and do "cvs checkout -r Ver_<MAJ>-<MIN>
   JSOC" and build on all machines supported.
   
   9. Once again, edit $JSOCROOT/base/jsoc_version.h.  The
   version macros should be of the form:
  
 #define jsoc_version "V3R5X" #define jsoc_version "V3R5X"
 #define jsoc_vers_num (-305) #define jsoc_vers_num (-305)
  
 The "X" and "-" denote that binaries were created from non-release code. The "X" and "-" denote that binaries were created from non-release code.
 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).  
 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.  10. From the machine used in step 9, commit
 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.  $JSOCROOT/base/jsoc_version.h.  You might have to run "cvs
   update -A base/jsoc_version.h" to clear the sticky flag created
   when you first sync'd in step 2 (if you used the "-r" flag).
   
 11. Send instructions for using the new release to users. 11. Send instructions for using the new release to users.
  
 ================================================================================ ================================================================================
Line 58  the working release get updated. WARNIN
Line 104  the working release get updated. WARNIN
 since by the time you see them, another user may have edited them. Only the production since by the time you see them, another user may have edited them. Only the production
 release is guaranteed to be stable and unchanged between releases. release is guaranteed to be stable and unchanged between releases.
  
 Updating to this release  Obtaining the Release
 -----------------------  ---------------------
 Once you have a sandbox, you may want to update it to this release so that you  To update your working directory to this release, or to check-out this release anew,
 get new functionality that is stable (the binaries build and run properly).  please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that
 The general way of doing this is to run "cvs update -APd -r Ver_3-8" from $JSOCROOT.  users may have modified files since the release was created, so use of the
 The "-r" flag tells cvs to ensure that all your local files have the versions that  scripts documented in the web page may result in a working directory whose
 compose the 3.8 Release.  You would then need to run "make" from $JSOCROOT to  content is not identical to the release.  If updating, you can supply
 build the binaries.  Alternatively, there is a script, $JSOCROOT/jsoc_update.csh  the flag "-R" to the jsoc_update.csh and jsoc_sync.csh scripts to download the
 that can be used to both update to the latest release and to build JSOC on all  latest release.  This will ensure that your working directory has the exact, latest
 supported machines.  To do this, run $JSOCROOT/jsoc_update.csh -R.  The "-R" flag  release versions of the files (eg., jsoc_sync.csh -R). If checking-out,
 tells cvs to update to the latest release before building on the supported  you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
 machine types.  This script generates log files for each machine type:  to achieve the analogous result, but for a fresh checkout.  WARNING: if you use
 $JSOCROOT/make_jsoc_linux_X86_64.log and $JSOCROOT/make_jsoc_linux_ia32.log.  the "-R" or "-r" flags, please use only jsoc_update.csh or jsoc_sync.csh to update
 You should examine these logs to look for errors.  Before updating to the release  your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
 with either of these alternatives, ensure that somewhere in your setup  "sticky flag" being set.  jsoc_update.csh and jsoc_sync.csh clear this sticky flag.
 "source $HOME/.setJSOCenv" exists.  
   
 If You Don't Have a Sandbox  
 ---------------------------  
 You need a cvs "sandbox" to contain your view of a JSOC release:  
 (There is no need to do this unless you're going to be a jsoc developer.)  
   
 Set the env variables:  
 CVSROOT=:ext:sunroom.stanford.edu:/home/cvsuser/cvsroot  
 CVS_RSH=ssh  
   
 Make a cvs dir and do:  
 > cd /home/you/cvs  
 > cvs checkout JSOC  
   
 This will copy the LATEST version of all cvs depot files to /home/you/cvs/JSOC.  
 These are not guaranteed to be stable.  This is something you may want to do if  
 you are a developer, perhaps you are fixing a broken build.  If instead you want  
 this stable release, then substitute "cvs checkout -r Ver_3-8 JSOC" for the above  
 "cvs checkout JSOC" command.  
   
 You would then make changes to the checked-out files, and commit them back to the  
 depot with the "cvs commit files..." command.  Only after running this command  
 can users "see" your changes.  To "see" your changes, a user would need to update  
 their sandbox with the latest changes to the depot ("cd $JSOCROOT; cvs update -APd" )  
  
 Additional Info Additional Info
 --------------- ---------------

Legend:
Removed from v.1.3  
changed lines
  Added in v.1.12
Karen Tian
 Powered by
ViewCVS 0.9.4