| 8 |
|
|
| 9 |
|
3. Repeat step 2 for all machine types supported. |
| 10 |
|
4. From the machine used in step 2, commit $JSOCROOT/base/libdrms/jsoc_version.h. |
| 11 |
+ |
4a. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the release notes (see below). Commit. |
| 12 |
|
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. |
| 13 |
+ |
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> {} \; \)" |
| 14 |
|
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. |
| 15 |
|
7. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h. The version macros should be of the form: |
| 16 |
|
|
| 21 |
|
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). |
| 22 |
|
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. |
| 23 |
|
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. |
| 24 |
< |
11. Send instructions for using the new release to users. |
| 24 |
> |
12. Send instructions for using the new release to users. |
| 25 |
|
|
| 26 |
|
================================================================================ |
| 27 |
|
Example New Release Instructions |
| 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 |
< |
----------------------- |
| 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 |
| 76 |
< |
"source $HOME/.setJSOCenv" exists. |
| 77 |
< |
|
| 78 |
< |
If You Don't Have a Sandbox |
| 79 |
< |
--------------------------- |
| 80 |
< |
You need a cvs "sandbox" to contain your view of a JSOC release: |
| 81 |
< |
(There is no need to do this unless you're going to be a jsoc developer.) |
| 82 |
< |
|
| 83 |
< |
Set the env variables: |
| 84 |
< |
CVSROOT=:ext:sunroom.stanford.edu:/home/cvsuser/cvsroot |
| 85 |
< |
CVS_RSH=ssh |
| 86 |
< |
|
| 87 |
< |
Make a cvs dir and do: |
| 88 |
< |
> cd /home/you/cvs |
| 89 |
< |
> cvs checkout JSOC |
| 90 |
< |
|
| 91 |
< |
This will copy the LATEST version of all cvs depot files to /home/you/cvs/JSOC. |
| 92 |
< |
These are not guaranteed to be stable. This is something you may want to do if |
| 93 |
< |
you are a developer, perhaps you are fixing a broken build. If instead you want |
| 94 |
< |
this stable release, then substitute "cvs checkout -r Ver_3-8 JSOC" for the above |
| 95 |
< |
"cvs checkout JSOC" command. |
| 96 |
< |
|
| 97 |
< |
You would then make changes to the checked-out files, and commit them back to the |
| 98 |
< |
depot with the "cvs commit files..." command. Only after running this command |
| 99 |
< |
can users "see" your changes. To "see" your changes, a user would need to update |
| 100 |
< |
their sandbox with the latest changes to the depot ("cd $JSOCROOT; cvs update -APd" ) |
| 63 |
> |
Obtaining the Release |
| 64 |
> |
--------------------- |
| 65 |
> |
To update your working directory to this release, or to check-out this release anew, |
| 66 |
> |
please visit http://jsoc.stanford.edu/jsocwiki/CvsInit. Please keep in mind that |
| 67 |
> |
users may have modified files since the release was created, so use of the |
| 68 |
> |
scripts documented in the web page may result in a working directory whose |
| 69 |
> |
content is not identical to the release. If updating, you can supply |
| 70 |
> |
the flag "-R" to the jsoc_update.csh and jsoc_sync.csh scripts to download the |
| 71 |
> |
latest release. This will ensure that your working directory has the exact, latest |
| 72 |
> |
release versions of the files (eg., jsoc_sync.csh -R). If checking-out, |
| 73 |
> |
you can supply the argument "-r Ver_LATEST" to the "cvs checkout" command |
| 74 |
> |
to achieve the analogous result, but for a fresh checkout. WARNING: if you use |
| 75 |
> |
the "-R" or "-r" flags, please use only jsoc_update.csh or jsoc_sync.csh to update |
| 76 |
> |
your sources thereafter. Use of "-R" or "-r Ver_LATEST" will result in a cvs |
| 77 |
> |
"sticky flag" being set. jsoc_update.csh and jsoc_sync.csh clear this sticky flag. |
| 78 |
|
|
| 79 |
|
Additional Info |
| 80 |
|
--------------- |
