1 arta  1.1 Art's suggested release recipe:
  2           

  3 arta  1.8 1. Notify users (jsoc_dev@sun.stanford.edu) that a new release will be
  4           built.  Allow users time to submit changes they want in the new
  5           release.  This includes changes made by the CM that have not been
  6           committed.  
  7           
  8           2. From a cluster-node (eg., n00), perform a clean sync to
  9           head as a non-Production user (cvs checkout -r HEAD JSOC).  The -r rev
 10           option is sticky, which means that if you used -r Ver_3-2 on a
 11           previous checkout, that "cvs checkout JSOC" will check out Ver_3-2.
 12           Use "-r HEAD" to force the use of the head revision. 
 13           
 14           3.Update $JSOCROOT/base/jsoc_version.h to the latest release version
 15           and build again (make clean, make universe).  The version macros
 16           should be of the form:

 17 arta  1.1 
 18           #define jsoc_version "V3R5"
 19           #define jsoc_vers_num (305)
 20           

 21 arta  1.3 4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h.

 22 arta  1.8 
 23           5. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the
 24           release notes (see below).  Commit.
 25           
 26           6. From the machine used in step 2, create a tag for the new release.
 27           cd to $JSOCROOT.  Run "cvs tag -c Ver_<MAJ>-<MIN> ."  Replace <MAJ>
 28           with the major version number and <MIN> with the minor version number.
 29           
 30           7. The NetDRMS release version number should also be incremented and
 31           tagged. Do "cvs checkout -r Ver_<MAJ>-<MIN> DRMS" followed by "cd
 32           $JSOCROOT; cvs tag -c NetDRMS_Ver_<MAJ>-<MIN>".
 33           
 34           8. Update the "Ver_LATEST" tag.  This tag always points to the latest
 35           release.  "cvs tag -d Ver_LATEST .; cd $JSOCROOT; cvs rtag -r
 36           Ver_<MAJ>-<MIN> Ver_LATEST JSOC", where <MAJ> and <MIN> are the
 37           current release.  Alternatively, try "cvs tag -d Ver_LATEST .; cd
 38           tempdir; cvs checkout -r Ver_<MAJ>-<MIN> JSOC" followed by "cvs tag -c
 39           Ver_LATEST".
 40           
 41           9. Now you must build all release executables with the release jsoc
 42           version numbers in place ("V3R5" and "305" in this example). Ensure
 43 arta  1.8 that the tag was successfully created and create actual release
 44           binaries (not just the binaries in your sandbox).  Login as the 'jsoc'
 45           user, cd to /home/jsoc/cvs, and do "cvs checkout -r Ver_<MAJ>-<MIN>
 46           JSOC" and build on all machines supported.  
 47           
 48           9. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h.  The
 49           version macros should be of the form:

 50 arta  1.1 
 51           #define jsoc_version "V3R5X"
 52           #define jsoc_vers_num (-305)
 53           
 54           The "X" and "-" denote that binaries were created from non-release code.

 55 arta  1.7 

 56 arta  1.8 10. From the machine used in step 9, commit
 57           $JSOCROOT/base/libdrms/jsoc_version.h.  You might have to run "cvs
 58           update -A base/libdrms/jsoc_version.h" to clear the sticky flag created
 59           when you first sync'd in step 2 (if you used the "-r" flag).
 60           
 61           11. Send instructions for using the new release to users.

 62 arta  1.1 
 63           ================================================================================
 64           Example New Release Instructions
 65           
 66           
 67                                  Release Notes JSOC V3.8         12Sep2007
 68                                  -----------------------         ---------
 69           
 70           A release is a set of files, each having a specific version.  And a release typcially
 71           has a version number because over time you have newer and newer releases of the 
 72           same product.  For example, a hypothetical 1.3 release may contain fileA#1.8, 
 73           fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. 
 74           JSOC releases are similarly versioned and contain a set of such files.  JSOC release
 75           code is guaranteed to compile on cluster nodes (eg., n00, n02).  The resulting binaries
 76           have been minimally tested.  At the time of the creation of the release, the
 77           release versions of each file will be the most recent.  But as time passes, newer versions 
 78           of some files will be made, and there is no guarantee that these changes will
 79           not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute
 80           properly).  
 81           
 82           There are several ways to use this release.  If you wish to simply use pre-built
 83 arta  1.1 binaries, you can simply use the production binaries, which are located at 

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

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

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

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

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

 94 arta  1.1 files may be placed here and existing files may be edited for common use before the 
 95           next official release.  Each time a release gets created, the source and binaries of 
 96           the working release get updated.  WARNING: the files you see here may not be stable 
 97           since by the time you see them, another user may have edited them. Only the production 
 98           release is guaranteed to be stable and unchanged between releases.
 99           

100 arta  1.4 Obtaining the Release
101           ---------------------
102           To update your working directory to this release, or to check-out this release anew, 
103           please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that
104           users may have modified files since the release was created, so use of the 
105           scripts documented in the web page may result in a working directory whose
106           content is not identical to the release.  If updating, you can supply 
107           the flag "-R" to the jsoc_update.csh and jsoc_sync.csh scripts to download the
108           latest release.  This will ensure that your working directory has the exact, latest
109           release versions of the files (eg., jsoc_sync.csh -R). If checking-out, 
110           you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command
111           to achieve the analogous result, but for a fresh checkout.  WARNING: if you use 
112           the "-R" or "-r" flags, please use only jsoc_update.csh or jsoc_sync.csh to update 
113           your sources thereafter.  Use of "-R" or "-r Ver_LATEST" will result in a cvs
114           "sticky flag" being set.  jsoc_update.csh and jsoc_sync.csh clear this sticky flag.

115 arta  1.1 
116           Additional Info
117           ---------------
118           If you are unfamiliar with the use of cvs see the file:

119 arta  1.3 JSOC/CM/working_with_sandbox.txt.

120 arta  1.1 
121           There's a linux4 cvs gui at xim:/usr/bin/lincvs
122           Also on our jsoc web page:
123           

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

125 arta  1.1 
126           Use the Apache cvs gui to see the diffs. For example, go to

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

128 arta  1.1 and click on the name in the File column and then click on
129           "diffs to previous #" to see the diffs.
130           
131           End Example New Release Instructions
132           ================================================================================
133           
134           --Art Amezcua 9/12/2007
135           
136           
137           
138           

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

140 arta  1.1 

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

142 arta  1.1 
143           A release is done from a sandbox. Get the production user sandbox to work:
144           

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

146 arta  1.1 

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

148 arta  1.1 
149           Do a sanity check on the make log files:
150           $JSOCROOT/make_jsoc_linux_X86_64.log
151           #$JSOCROOT/make_jsoc_linux_ia64.log
152           $JSOCROOT/make_jsoc_linux_ia32.log
153           
154           
155           -----------------------------------------------------------------------------
156           When all the makes are ok, tag all the most recent revisions in the repository:
157           

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

159 arta  1.1 
160           To remove this tag do:
161           

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

163 arta  1.1 

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

165 arta  1.1 their release update.
166           
167           
168           
169           ***************OLD STUFF BELOW******************************************
170           -----------------------------------------------------------------------------
171           
172           Resync with the repository:
173           
174           > cvs update -APd >& cvsupdate.log
175           
176           Inspect cvsupdate.log for any "C " status.
177           
178                  C file
179                    A  conflict  was detected while trying to merge your changes to file
180                    with changes from the source repository.  file  (the  copy  in  your
181                    working  directory) is now the result of attempting to merge the two
182                    revisions; an unmodified copy of your file is also in  your  working
183                    directory, with the name .#file.revision where revision is the revi-
184                    sion that your modified file started from.  Resolve the conflict 
185           
186 arta  1.1 -----------------------------------------------------------------------------
187           Check for any files that have not been commited (not Status: Up-to-date):
188           
189           > cvsstatus	(NOTE: s/b an alias for $JSOCROOT/scripts/cvsstatus.pl)
190           
191           Determine if any modified files need to be committed or replaced with the
192           repository version before proceeding.
193           
194           -----------------------------------------------------------------------------
195           Get the all the makes to work:
196           > ssh production@lws               (and then again for d00 and n00(32bit))

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

198 arta  1.1 ####(OLD) > setenv ORACLE_HOME /u01/app/oracle/product/10.1.0/db_1
199           > ./configure -force  (for n00: ./configure -force -client)
200           (may have to do a make cleandep; make depend)
201           (ignore modification time in future msgs)
202           
203           > make clean
204           > make -j 4 >& make.log.lws        (run 4 jobs in parallel for speed)
205           
206           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
207           !!!!!!!!!!!!!!!!!Check that libsum, sumsapi, and sum dirs use gcc !!!!!!!!!!!
208           !!!!!!!!!!! Don't have to do this if gcc is already in the Makefile !!!!!!!!!
209           Now go to the dirs that need to have the gcc compile and edit Makefile:

210 arta  1.2 cd /home2/production/cvs/JSOC/base/
211           cd sums/libs/pg

212 arta  1.1 vi Makefile
213           ***ADD after the line:
214           include ../../make.mk
215           
216           ###Mod by JA after configure is run#########################
217           CC = gcc
218           CFLAGS = -std=gnu99 -g -Wall -O0 -Wno-comment -Wno-parentheses
219           
220           And then do
221           >make clean
222           >make
223           And do the same for cd ../sumsapi/ and cd ../sum/
224           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
225           
226           
227