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.9 4. From the machine used in step 2, commit $JSOCROOT/base/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 arta  1.10   a. cd $JSOCROOT
 28              b. cvs tag -c Ver_<MAJ>-<MIN> . (Replace <MAJ>
 29            with the major version number and <MIN> with the minor version number.)
 30              c. cvs tag -d Ver_LATEST .
 31              d. cvs tag -c Ver_LATEST .

 32 arta  1.8  
 33            7. The NetDRMS release version number should also be incremented and

 34 arta  1.10 tagged:
 35              a. cd /tmp

 36 arta  1.11   b. cvs checkout NETDRMSONLY (head version of netdrms-only files)
 37              c. cd JSOC

 38 arta  1.12   d. cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> .
 39              e. cvs tag -d Ver_DRMSLATEST .
 40              f. cvs tag -c Ver_DRMSLATEST .

 41 arta  1.11   g. cd /tmp
 42              h. cvs checkout -r Ver_<MAJ>-<MIN> CORE 
 43              i. cd JSOC

 44 arta  1.12   j. cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> . (minus excluded files)
 45              k. cvs tag -d Ver_DRMSLATEST .
 46              l. cvs tag -c Ver_DRMSLATEST . (minus excluded files)
 47            

 48 arta  1.10 8. Now you must build all release executables with the release jsoc

 49 arta  1.8  version numbers in place ("V3R5" and "305" in this example). Ensure
 50            that the tag was successfully created and create actual release
 51            binaries (not just the binaries in your sandbox).  Login as the 'jsoc'
 52            user, cd to /home/jsoc/cvs, and do "cvs checkout -r Ver_<MAJ>-<MIN>
 53            JSOC" and build on all machines supported.  
 54            

 55 arta  1.9  9. Once again, edit $JSOCROOT/base/jsoc_version.h.  The

 56 arta  1.8  version macros should be of the form:

 57 arta  1.1  
 58            #define jsoc_version "V3R5X"
 59            #define jsoc_vers_num (-305)
 60            
 61            The "X" and "-" denote that binaries were created from non-release code.

 62 arta  1.7  

 63 arta  1.8  10. From the machine used in step 9, commit

 64 arta  1.9  $JSOCROOT/base/jsoc_version.h.  You might have to run "cvs
 65            update -A base/jsoc_version.h" to clear the sticky flag created

 66 arta  1.8  when you first sync'd in step 2 (if you used the "-r" flag).
 67            
 68            11. Send instructions for using the new release to users.

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

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

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

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

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

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

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

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

122 arta  1.1  
123            Additional Info
124            ---------------
125            If you are unfamiliar with the use of cvs see the file:

126 arta  1.3  JSOC/CM/working_with_sandbox.txt.

127 arta  1.1  
128            There's a linux4 cvs gui at xim:/usr/bin/lincvs
129            Also on our jsoc web page:
130            

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

132 arta  1.1  
133            Use the Apache cvs gui to see the diffs. For example, go to

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

135 arta  1.1  and click on the name in the File column and then click on
136            "diffs to previous #" to see the diffs.
137            
138            End Example New Release Instructions
139            ================================================================================
140            
141            --Art Amezcua 9/12/2007
142            
143            
144            
145            

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

147 arta  1.1  

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

149 arta  1.1  
150            A release is done from a sandbox. Get the production user sandbox to work:
151            

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

153 arta  1.1  

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

155 arta  1.1  
156            Do a sanity check on the make log files:
157            $JSOCROOT/make_jsoc_linux_X86_64.log
158            #$JSOCROOT/make_jsoc_linux_ia64.log
159            $JSOCROOT/make_jsoc_linux_ia32.log
160            
161            
162            -----------------------------------------------------------------------------
163            When all the makes are ok, tag all the most recent revisions in the repository:
164            

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

166 arta  1.1  
167            To remove this tag do:
168            

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

170 arta  1.1  

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

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

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

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

217 arta  1.2  cd /home2/production/cvs/JSOC/base/
218            cd sums/libs/pg

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