JSOC/CM/release.howto - diff

Return to release.howto CVS log

Up to [Development] / JSOC / CM

Diff for /JSOC/CM/release.howto between version 1.2 and 1.13

version 1.2, 2007/10/17 14:53:42

version 1.13, 2011/06/02 23:30:38

Line 1

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.

1. Notify users (jsoc_dev@sun.stanford.edu) that a new release will be

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.

built. Allow users time to submit changes they want in the new

3. From one machine, update $JSOCROOT/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:

release. This includes changes made by the CM that have not been

committed.

2. 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)

4. Build all binaries (ie., make universe) and ensure there are no make problems.

cvs commit $JSOCROOT/base/jsoc_version.h.

5. Repeat 2 and 4 for all machine types supported.

6. From the machine used in step 3, commit $JSOCROOT/base/libdrms/jsoc_version.h.

3. Add a new file, JSOC/CM/V<MAJ>.<MIN>/release.notes. This has the

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.

release notes (see below). Commit.

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.

9. Once again, edit $JSOCROOT/base/libdrms/jsoc_version.h. The version macros should be of the form:

4. Create a tag for the new release.

a. Create the full-JSOC-release tags

i. /home/jsoc/dlsource.pl -o tag -f sdp -t Ver_<MAJ>-<MIN>

ii. /home/jsoc/dlsource.pl -o untag -f sdp -t Ver_LATEST

iii. /home/jsoc/dlsource.pl -o tag -f sdp -t Ver_LATEST

b. Create the NetDRMS-release tags

i. /home/jsoc/dlsource.pl -o tag -f net -t NetDRMS_Ver_<MAJ>-<MIN>

ii. /home/jsoc/dlsource.pl -o untag -f net -t Ver_DRMSLATEST

iii. /home/jsoc/dlsource.pl -o tag -f net -t Ver_DRMSLATEST

5. Now you must build all production release executables with the release jsoc

version numbers in place ("V3R5" and "305" in this example). Ensure

that the tag was successfully created and create actual release

binaries (not just the binaries in your sandbox). Login as the 'jsoc'

user, cd to /home/jsoc/cvs, and run "/home/jsoc/dlsource.pl -o checkout

-f sdp -r Ver_<MAJ>-<MIN>" and build on all machines supported. Do the same in

/home/jsoc/cvs/Development/.

6. Edit $JSOCROOT/base/jsoc_version.h, but not the version of this file

in a production directory.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.

10. From the machine used in step 8, 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).

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.

commit $JSOCROOT/base/jsoc_version.h.

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.

13. Send instructions for using the new release to users.

7. Send instructions for using the new release to users.

================================================================================

Example New Release Instructions

Line 44 properly).

Line 68 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

/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.

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

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

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

---------------

If you are unfamiliar with the use of cvs see the file:

jsoc/CM/working_with_sandbox.txt.

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/

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/

Line 124 End Example New Release Instructions

Line 123 End Example New Release Instructions

/home/jim/cvs/jsoc/CM/release.howto

/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

> cd /home/production/cvs/JSOC

d00:/home/production/cvs/jsoc> $JSOCROOT/jsoc_update.csh

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

Line 143 $JSOCROOT/make_jsoc_linux_ia32.log

Line 142 $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

> 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

> 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

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

their release update.

Line 182 repository version before proceeding.

Line 181 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

> 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)

Legend:

Removed from v.1.2
changed lines
	Added in v.1.13

Karen Tian