1 arta  1.1 Art's suggested release recipe:
  2           
  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.
  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.
  5           3. From one machine, update $JSOCROOT/src/base/libdrms/jsoc_version.h to the latest release version and build again (make clean, make universe).  The version macros should be of the form:
  6           
  7           #define jsoc_version "V3R5"
  8           #define jsoc_vers_num (305)
  9           
 10           4. Build all binaries (ie., make universe) and ensure there are no make problems.
 11           5. Repeat 2 and 4 for all machine types supported.
 12           6. From the machine used in step 3, commit $JSOCROOT/src/base/libdrms/jsoc_version.h.
 13           7. From the machine used in step 3, 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.
 14           8. 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           9. Once again, edit $JSOCROOT/src/base/libdrms/jsoc_version.h.  The version macros should be of the form:
 16           
 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           10. From the machine used in step 8, commit $JSOCROOT/src/base/libdrms/jsoc_version.h.  You might have to run "cvs update -A src/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.1 11. 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           12. 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           13. Send instructions for using the new release to users.
 25           
 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 arta  1.1 properly).  
 44           
 45           There are several ways to use this release.  If you wish to simply use pre-built
 46           binaries, you can simply use the production binaries, which are located at 
 47           /home/production/cvs/jsoc.  Every time a release is created, the binaries in
 48           this location get updated.  Only the production user can update these binaries.
 49           So, you could run /home/production/cvs/jsoc/bin/linux_x86_64/show_keys, for example.
 50           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           There is also a "working" release which resides in in /home/jsoc/cvs/jsoc.  New 
 57           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           Updating to this release
 64 arta  1.1 -----------------------
 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 
 78           "source $HOME/.setJSOCenv" exists.  
 79           
 80           If You Don't Have a Sandbox 
 81           ---------------------------
 82           You need a cvs "sandbox" to contain your view of a JSOC release:
 83           (There is no need to do this unless you're going to be a jsoc developer.)
 84           
 85 arta  1.1 Set the env variables:
 86           CVSROOT=:ext:sunroom.stanford.edu:/home/cvsuser/cvsroot
 87           CVS_RSH=ssh
 88           
 89           Make a cvs dir and do:
 90           > cd /home/you/cvs
 91           > cvs checkout jsoc
 92           
 93           This will copy the LATEST version of all cvs depot files to /home/you/cvs/jsoc.
 94           These are not guaranteed to be stable.  This is something you may want to do if 
 95           you are a developer, perhaps you are fixing a broken build.  If instead you want 
 96           this stable release, then substitute "cvs checkout -r Ver_3-8 jsoc" for the above 
 97           "cvs checkout jsoc" command.
 98           
 99           You would then make changes to the checked-out files, and commit them back to the
100           depot with the "cvs commit files..." command.  Only after running this command
101           can users "see" your changes.  To "see" your changes, a user would need to update
102           their sandbox with the latest changes to the depot ("cd $JSOCROOT; cvs update -APd" )
103           
104           Additional Info
105           ---------------
106 arta  1.1 If you are unfamiliar with the use of cvs see the file:
107           jsoc/CM/working_with_sandbox.txt.
108           
109           There's a linux4 cvs gui at xim:/usr/bin/lincvs
110           Also on our jsoc web page:
111           
112           http://jsoc.stanford.edu/cvs/jsoc/
113           
114           Use the Apache cvs gui to see the diffs. For example, go to
115           http://jsoc.stanford.edu/cvs/jsoc/src/base/libdrms/
116           and click on the name in the File column and then click on
117           "diffs to previous #" to see the diffs.
118           
119           End Example New Release Instructions
120           ================================================================================
121           
122           --Art Amezcua 9/12/2007
123           
124           
125           
126           
127 arta  1.1 					/home/jim/cvs/jsoc/CM/release.howto
128           
129           Make sure the cvs/jsoc/src/base/libdrms/jsoc_version.h is updated.
130           
131           A release is done from a sandbox. Get the production user sandbox to work:
132           
133           > cd /home/production/cvs/jsoc
134           
135           d00:/home/production/cvs/jsoc>  $JSOCROOT/jsoc_update.csh
136           
137           Do a sanity check on the make log files:
138           $JSOCROOT/make_jsoc_linux_X86_64.log
139           #$JSOCROOT/make_jsoc_linux_ia64.log
140           $JSOCROOT/make_jsoc_linux_ia32.log
141           
142           
143           -----------------------------------------------------------------------------
144           When all the makes are ok, tag all the most recent revisions in the repository:
145           
146           > cvs -d /home/cvsuser/cvsroot rtag -r HEAD Ver_1-0 jsoc
147           
148 arta  1.1 To remove this tag do:
149           
150           > cvs -d /home/cvsuser/cvsroot rtag -d Ver_1-0 jsoc
151           
152           NOTE: Tell users about Phil's script cvs/jsoc/jsoc_update.csh  to do
153           their release update.
154           
155           
156           
157           ***************OLD STUFF BELOW******************************************
158           -----------------------------------------------------------------------------
159           
160           Resync with the repository:
161           
162           > cvs update -APd >& cvsupdate.log
163           
164           Inspect cvsupdate.log for any "C " status.
165           
166                  C file
167                    A  conflict  was detected while trying to merge your changes to file
168                    with changes from the source repository.  file  (the  copy  in  your
169 arta  1.1          working  directory) is now the result of attempting to merge the two
170                    revisions; an unmodified copy of your file is also in  your  working
171                    directory, with the name .#file.revision where revision is the revi-
172                    sion that your modified file started from.  Resolve the conflict 
173           
174           -----------------------------------------------------------------------------
175           Check for any files that have not been commited (not Status: Up-to-date):
176           
177           > cvsstatus	(NOTE: s/b an alias for $JSOCROOT/scripts/cvsstatus.pl)
178           
179           Determine if any modified files need to be committed or replaced with the
180           repository version before proceeding.
181           
182           -----------------------------------------------------------------------------
183           Get the all the makes to work:
184           > ssh production@lws               (and then again for d00 and n00(32bit))
185           > cd /home/production/cvs/jsoc
186           ####(OLD) > setenv ORACLE_HOME /u01/app/oracle/product/10.1.0/db_1
187           > ./configure -force  (for n00: ./configure -force -client)
188           (may have to do a make cleandep; make depend)
189           (ignore modification time in future msgs)
190 arta  1.1 
191           > make clean
192           > make -j 4 >& make.log.lws        (run 4 jobs in parallel for speed)
193           
194           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
195           !!!!!!!!!!!!!!!!!Check that libsum, sumsapi, and sum dirs use gcc !!!!!!!!!!!
196           !!!!!!!!!!! Don't have to do this if gcc is already in the Makefile !!!!!!!!!
197           Now go to the dirs that need to have the gcc compile and edit Makefile:
198           cd /home2/production/cvs/jsoc/src/base/
199           cd libsum
200           vi Makefile
201           ***ADD after the line:
202           include ../../make.mk
203           
204           ###Mod by JA after configure is run#########################
205           CC = gcc
206           CFLAGS = -std=gnu99 -g -Wall -O0 -Wno-comment -Wno-parentheses
207           
208           And then do
209           >make clean
210           >make
211 arta  1.1 And do the same for cd ../sumsapi/ and cd ../sum/
212           ############## ONLY HAD TO DO THIS THE FIRST TIME ############################
213           
214           
215