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. 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: #define jsoc_version "V3R5" #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/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_- ." Replace with the major version number and with the minor version number. 6. Update the "Ver_LATEST" tag. This tag always points to the latest release. "cd $JSOCROOT; cvs rtag -r Ver_- Ver_LATEST JSOC", where and are the current release. 7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h. The version macros should be of the form: #define jsoc_version "V3R5X" #define jsoc_vers_num (-305) 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_- JSOC) and build on all machines supported. 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_- JSOC" and build on all machines supported. 11. Send instructions for using the new release to users. ================================================================================ Example New Release Instructions Release Notes JSOC V3.8 12Sep2007 ----------------------- --------- A release is a set of files, each having a specific version. And a release typcially has a version number because over time you have newer and newer releases of the same product. For example, a hypothetical 1.3 release may contain fileA#1.8, fileB#1.2, fileC#2.2 and a 1.4 release may contain fileA#2.5, fileB#2.1, fileC#2.9. JSOC releases are similarly versioned and contain a set of such files. JSOC release code is guaranteed to compile on cluster nodes (eg., n00, n02). The resulting binaries have been minimally tested. At the time of the creation of the release, the release versions of each file will be the most recent. But as time passes, newer versions of some files will be made, and there is no guarantee that these changes will not destabilize JSOC (ie., they may cause JSOC to no longer compile or execute properly). There are several ways to use this release. If you wish to simply use pre-built binaries, you can simply use the production binaries, which are located at /home/production/cvs/JSOC. Every time a release is created, the binaries in this location get updated. Only the production user can update these binaries. So, you could run /home/production/cvs/JSOC/bin/linux_x86_64/show_keys, for example. If instead you want to work with stable source files, then you must have a sandbox, which is a local copy (in your home directory) of the files in the cvs depot. You would probably want to work with a sandbox if you plan on making eventual changes to the depot files. Changes you make to your sandbox files are not visible to other users until you "commit" those changes back to the cvs depot. Please see "If You Don't Have a Sandbox" below for more information on how to create a sandbox. There is also a "working" release which resides in in /home/jsoc/cvs/JSOC. New files may be placed here and existing files may be edited for common use before the next official release. Each time a release gets created, the source and binaries of the working release get updated. WARNING: the files you see here may not be stable 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. Updating to this release ----------------------- Once you have a sandbox, you may want to update it to this release so that you get new functionality that is stable (the binaries build and run properly). The general way of doing this is to run "cvs update -APd -r Ver_3-8" from $JSOCROOT. The "-r" flag tells cvs to ensure that all your local files have the versions that compose the 3.8 Release. You would then need to run "make" from $JSOCROOT to build the binaries. Alternatively, there is a script, $JSOCROOT/jsoc_update.csh that can be used to both update to the latest release and to build JSOC on all supported machines. To do this, run $JSOCROOT/jsoc_update.csh -R. The "-R" flag tells cvs to update to the latest release before building on the supported machine types. This script generates log files for each machine type: $JSOCROOT/make_jsoc_linux_X86_64.log and $JSOCROOT/make_jsoc_linux_ia32.log. You should examine these logs to look for errors. Before updating to the release with either of these alternatives, ensure that somewhere in your setup "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 --------------- If you are unfamiliar with the use of cvs see the file: JSOC/CM/working_with_sandbox.txt. There's a linux4 cvs gui at xim:/usr/bin/lincvs Also on our jsoc web page: http://jsoc.stanford.edu/cvs/JSOC/ Use the Apache cvs gui to see the diffs. For example, go to http://jsoc.stanford.edu/cvs/JSOC/base/drms/ and click on the name in the File column and then click on "diffs to previous #" to see the diffs. End Example New Release Instructions ================================================================================ --Art Amezcua 9/12/2007 /home/jim/cvs/JSOC/CM/release.howto Make sure the cvs/JSOC/base/jsoc_version.h is updated. A release is done from a sandbox. Get the production user sandbox to work: > cd /home/production/cvs/JSOC d00:/home/production/cvs/JSOC> $JSOCROOT/jsoc_update.csh Do a sanity check on the make log files: $JSOCROOT/make_jsoc_linux_X86_64.log #$JSOCROOT/make_jsoc_linux_ia64.log $JSOCROOT/make_jsoc_linux_ia32.log ----------------------------------------------------------------------------- When all the makes are ok, tag all the most recent revisions in the repository: > cvs -d /home/cvsuser/cvsroot rtag -r HEAD Ver_1-0 JSOC To remove this tag do: > cvs -d /home/cvsuser/cvsroot rtag -d Ver_1-0 JSOC NOTE: Tell users about Phil's script cvs/JSOC/jsoc_update.csh to do their release update. ***************OLD STUFF BELOW****************************************** ----------------------------------------------------------------------------- Resync with the repository: > cvs update -APd >& cvsupdate.log Inspect cvsupdate.log for any "C " status. C file A conflict was detected while trying to merge your changes to file with changes from the source repository. file (the copy in your working directory) is now the result of attempting to merge the two revisions; an unmodified copy of your file is also in your working directory, with the name .#file.revision where revision is the revi- sion that your modified file started from. Resolve the conflict ----------------------------------------------------------------------------- Check for any files that have not been commited (not Status: Up-to-date): > cvsstatus (NOTE: s/b an alias for $JSOCROOT/scripts/cvsstatus.pl) Determine if any modified files need to be committed or replaced with the repository version before proceeding. ----------------------------------------------------------------------------- Get the all the makes to work: > ssh production@lws (and then again for d00 and n00(32bit)) > cd /home/production/cvs/JSOC ####(OLD) > setenv ORACLE_HOME /u01/app/oracle/product/10.1.0/db_1 > ./configure -force (for n00: ./configure -force -client) (may have to do a make cleandep; make depend) (ignore modification time in future msgs) > make clean > make -j 4 >& make.log.lws (run 4 jobs in parallel for speed) ############## ONLY HAD TO DO THIS THE FIRST TIME ############################ !!!!!!!!!!!!!!!!!Check that libsum, sumsapi, and sum dirs use gcc !!!!!!!!!!! !!!!!!!!!!! Don't have to do this if gcc is already in the Makefile !!!!!!!!! Now go to the dirs that need to have the gcc compile and edit Makefile: cd /home2/production/cvs/JSOC/base/ cd sums/libs/pg vi Makefile ***ADD after the line: include ../../make.mk ###Mod by JA after configure is run######################### CC = gcc CFLAGS = -std=gnu99 -g -Wall -O0 -Wno-comment -Wno-parentheses And then do >make clean >make And do the same for cd ../sumsapi/ and cd ../sum/ ############## ONLY HAD TO DO THIS THE FIRST TIME ############################