|
version 1.3, 2007/12/05 00:03:02
|
version 1.6, 2008/05/29 14:52:24
|
| Line 8 Art's suggested release recipe: |
|
| Line 8 Art's suggested release recipe: |
|
| | |
| 3. Repeat step 2 for all machine types supported. | 3. Repeat step 2 for all machine types supported. |
| 4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h. | 4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h. |
| |
4a. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the release notes (see below). Commit. |
| 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. | 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. |
| 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. |
5a. The NetDRMS release version number should also be incremented and tagged. From another machine, do "cvs checkout -AP DRMS". Then cd to the root (JSOC). Then "find . -path '*CVS' -prune -o \( -type f -exec cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> {} \; \)". Actually, the commands "cvs checkout -r Ver_<MAJ>-<MIN> DRMS" followed by "cd $JSOCROOT; cvs tag -c NetDRMS_Ver_<MAJ>-<MIN> will work". |
| |
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". |
| 7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h. The version macros should be of the form: | 7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h. The version macros should be of the form: |
| | |
| #define jsoc_version "V3R5X" | #define jsoc_version "V3R5X" |
| Line 19 The "X" and "-" denote that binaries wer |
|
| Line 21 The "X" and "-" denote that binaries wer |
|
| 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). | 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_<MAJ>-<MIN> JSOC) and build on all machines supported. | 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_<MAJ>-<MIN> 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_<MAJ>-<MIN> 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_<MAJ>-<MIN> JSOC" and build on all machines supported. |
| 11. Send instructions for using the new release to users. |
12. Send instructions for using the new release to users. |
| | |
| ================================================================================ | ================================================================================ |
| Example New Release Instructions | Example New Release Instructions |
| Line 58 the working release get updated. WARNIN |
|
| Line 60 the working release get updated. WARNIN |
|
| since by the time you see them, another user may have edited them. Only the production | 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. | release is guaranteed to be stable and unchanged between releases. |
| | |
| Updating to this release |
Obtaining the Release |
| ----------------------- |
--------------------- |
| Once you have a sandbox, you may want to update it to this release so that you |
To update your working directory to this release, or to check-out this release anew, |
| get new functionality that is stable (the binaries build and run properly). |
please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that |
| The general way of doing this is to run "cvs update -APd -r Ver_3-8" from $JSOCROOT. |
users may have modified files since the release was created, so use of the |
| The "-r" flag tells cvs to ensure that all your local files have the versions that |
scripts documented in the web page may result in a working directory whose |
| compose the 3.8 Release. You would then need to run "make" from $JSOCROOT to |
content is not identical to the release. If updating, you can supply |
| build the binaries. Alternatively, there is a script, $JSOCROOT/jsoc_update.csh |
the flag "-R" to the jsoc_update.csh and jsoc_sync.csh scripts to download the |
| that can be used to both update to the latest release and to build JSOC on all |
latest release. This will ensure that your working directory has the exact, latest |
| supported machines. To do this, run $JSOCROOT/jsoc_update.csh -R. The "-R" flag |
release versions of the files (eg., jsoc_sync.csh -R). If checking-out, |
| tells cvs to update to the latest release before building on the supported |
you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command |
| machine types. This script generates log files for each machine type: |
to achieve the analogous result, but for a fresh checkout. WARNING: if you use |
| $JSOCROOT/make_jsoc_linux_X86_64.log and $JSOCROOT/make_jsoc_linux_ia32.log. |
the "-R" or "-r" flags, please use only jsoc_update.csh or jsoc_sync.csh to update |
| You should examine these logs to look for errors. Before updating to the release |
your sources thereafter. Use of "-R" or "-r Ver_LATEST" will result in a cvs |
| with either of these alternatives, ensure that somewhere in your setup |
"sticky flag" being set. jsoc_update.csh and jsoc_sync.csh clear this sticky flag. |
| "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 | Additional Info |
| --------------- | --------------- |
Return to
release.howto
CVS log
Up to [Development] / JSOC / CM