1 arta  1.1 Art's suggested release recipe:
  2           

  3 arta  1.3 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.
  4           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:

  5 arta  1.1 
  6           #define jsoc_version "V3R5"
  7           #define jsoc_vers_num (305)
  8           

  9 arta  1.3 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 arta  1.4 4a. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the release notes (see below).  Commit.

 12 arta  1.3 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 arta  1.7 5a. The NetDRMS release version number should also be incremented and tagged. Do "cvs checkout -r Ver_<MAJ>-<MIN> DRMS" followed by "cd $JSOCROOT; cvs tag -c NetDRMS_Ver_<MAJ>-<MIN>".

 14 arta  1.6 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.  If that doesn't work try "cvs tag -d Ver_LATEST .; cvs checkout -r Ver_<MAJ>-<MIN> JSOC" followed by "cvs tag -c Ver_LATEST".

 15 arta  1.3 7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h.  The version macros should be of the form:

 16 arta  1.1 
 17           #define jsoc_version "V3R5X"
 18           #define jsoc_vers_num (-305)
 19           
 20           The "X" and "-" denote that binaries were created from non-release code.

 21 arta  1.3 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 arta  1.7 9. Now you must build all release executables with the release jsoc version numbers in place ("V3R5" and "305"). 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.  You must use the "-r" flag, otherwise you will checkout the latest jsoc_version.h, which has the DEVELOPMENT version of the release numbers.
 23           
 24           10. Send instructions for using the new release to users.

 25 arta  1.1 
 26           ================================================================================
 27           Example New Release Instructions
 28           
 29           
 30                                  Release Notes JSOC V3.8         12Sep2007
 31                                  -----------------------         ---------
 32           
 33           A release is a set of files, each having a specific version.  And a release typcially
 34           has a version number because over time you have newer and newer releases of the 
 35           same product.  For example, a hypothetical 1.3 release may contain fileA#1.8, 
 36           fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. 
 37           JSOC releases are similarly versioned and contain a set of such files.  JSOC release
 38           code is guaranteed to compile on cluster nodes (eg., n00, n02).  The resulting binaries
 39           have been minimally tested.  At the time of the creation of the release, the
 40           release versions of each file will be the most recent.  But as time passes, newer versions 
 41           of some files will be made, and there is no guarantee that these changes will
 42           not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute
 43           properly).  
 44           
 45           There are several ways to use this release.  If you wish to simply use pre-built
 46 arta  1.1 binaries, you can simply use the production binaries, which are located at 

 47 arta  1.3 /home/production/cvs/JSOC.  Every time a release is created, the binaries in

 48 arta  1.1 this location get updated.  Only the production user can update these binaries.

 49 arta  1.3 So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example.

 50 arta  1.1 If instead you want to work with stable source files, then you must have a sandbox,
 51           which is a local copy (in your home directory) of the files in the cvs depot.  
 52           You would probably want to work with a sandbox if you plan on making eventual 
 53           changes to the depot files.  Changes you make to your sandbox files are not visible 
 54           to other users until you "commit" those changes back to the cvs depot.  Please see
 55           "If You Don't Have a Sandbox" below for more information on how to create a sandbox.  

 56 arta  1.3 There is also a "working" release which resides in in /home/jsoc/cvs/JSOC.  New 

 57 arta  1.1 files may be placed here and existing files may be edited for common use before the 
 58           next official release.  Each time a release gets created, the source and binaries of 
 59           the working release get updated.  WARNING: the files you see here may not be stable 
 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.
 62           

 63 arta  1.4 Obtaining the Release
 64           ---------------------
 65           To update your working directory to this release, or to check-out this release anew, 
 66           please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. 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.

 78 arta  1.1 
 79           Additional Info
 80           ---------------
 81           If you are unfamiliar with the use of cvs see the file:

 82 arta  1.3 JSOC/CM/working_with_sandbox.txt.

 83 arta  1.1 
 84           There's a linux4 cvs gui at xim:/usr/bin/lincvs
 85           Also on our jsoc web page:
 86           

 87 arta  1.3 http://jsoc.stanford.edu/cvs/JSOC/

 88 arta  1.1 
 89           Use the Apache cvs gui to see the diffs. For example, go to

 90 arta  1.2 http://jsoc.stanford.edu/cvs/JSOC/base/drms/

 91 arta  1.1 and click on the name in the File column and then click on
 92           "diffs to previous #" to see the diffs.
 93           
 94           End Example New Release Instructions
 95           ================================================================================
 96           
 97           --Art Amezcua 9/12/2007
 98           
 99           
100           
101           

102 arta  1.3 					/home/jim/cvs/JSOC/CM/release.howto

103 arta  1.1 

104 arta  1.2 Make sure the cvs/JSOC/base/jsoc_version.h is updated.

105 arta  1.1 
106           A release is done from a sandbox. Get the production user sandbox to work:
107           

108 arta  1.3 > cd /home/production/cvs/JSOC

109 arta  1.1 

110 arta  1.3 d00:/home/production/cvs/JSOC>  $JSOCROOT/jsoc_update.csh

111 arta  1.1 
112           Do a sanity check on the make log files:
113           $JSOCROOT/make_jsoc_linux_X86_64.log
114           #$JSOCROOT/make_jsoc_linux_ia64.log
115           $JSOCROOT/make_jsoc_linux_ia32.log
116           
117           
118           -----------------------------------------------------------------------------
119           When all the makes are ok, tag all the most recent revisions in the repository:
120           

121 arta  1.3 > cvs -d /home/cvsuser/cvsroot rtag -r HEAD Ver_1-0 JSOC

122 arta  1.1 
123           To remove this tag do:
124           

125 arta  1.3 > cvs -d /home/cvsuser/cvsroot rtag -d Ver_1-0 JSOC

126 arta  1.1 

127 arta  1.3 NOTE: Tell users about Phil's script cvs/JSOC/jsoc_update.csh  to do

128 arta  1.1 their release update.
129           
130           
131           
132           ***************OLD STUFF BELOW******************************************
133           -----------------------------------------------------------------------------
134           
135           Resync with the repository:
136           
137           > cvs update -APd >& cvsupdate.log
138           
139           Inspect cvsupdate.log for any "C " status.
140           
141                  C file
142                    A  conflict  was detected while trying to merge your changes to file
143                    with changes from the source repository.  file  (the  copy  in  your
144                    working  directory) is now the result of attempting to merge the two
145                    revisions; an unmodified copy of your file is also in  your  working
146                    directory, with the name .#file.revision where revision is the revi-
147                    sion that your modified file started from.  Resolve the conflict 
148           
149 arta  1.1 -----------------------------------------------------------------------------
150           Check for any files that have not been commited (not Status: Up-to-date):
151           
152           > cvsstatus	(NOTE: s/b an alias for $JSOCROOT/scripts/cvsstatus.pl)
153           
154           Determine if any modified files need to be committed or replaced with the
155           repository version before proceeding.
156           
157           -----------------------------------------------------------------------------
158           Get the all the makes to work:
159           > ssh production@lws               (and then again for d00 and n00(32bit))

160 arta  1.3 > cd /home/production/cvs/JSOC

161 arta  1.1 ####(OLD) > setenv ORACLE_HOME /u01/app/oracle/product/10.1.0/db_1
162           > ./configure -force  (for n00: ./configure -force -client)
163           (may have to do a make cleandep; make depend)
164           (ignore modification time in future msgs)
165           
166           > make clean
167           > make -j 4 >& make.log.lws        (run 4 jobs in parallel for speed)
168           
169           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
170           !!!!!!!!!!!!!!!!!Check that libsum, sumsapi, and sum dirs use gcc !!!!!!!!!!!
171           !!!!!!!!!!! Don't have to do this if gcc is already in the Makefile !!!!!!!!!
172           Now go to the dirs that need to have the gcc compile and edit Makefile:

173 arta  1.2 cd /home2/production/cvs/JSOC/base/
174           cd sums/libs/pg

175 arta  1.1 vi Makefile
176           ***ADD after the line:
177           include ../../make.mk
178           
179           ###Mod by JA after configure is run#########################
180           CC = gcc
181           CFLAGS = -std=gnu99 -g -Wall -O0 -Wno-comment -Wno-parentheses
182           
183           And then do
184           >make clean
185           >make
186           And do the same for cd ../sumsapi/ and cd ../sum/
187           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
188           
189           
190