Creating a New Release

Organising the new release

You should let the programming team (Bernie included) when you plan on creating the new release. This way they can save any bug fixes that they are working on. The new release will not affect the work that they are currently doing. It just means that fixes that they save now will be transferred to the new release

Creating the release environment

There is a script called NewRelease under /u/ccdev/script/.

Because the script is not perfect and things are bound to go wrong, the script will not call the new release ccdev. It is up to you to decide that the new release is ready for use. It will:

• Create the necessary folder structure for the new release
• Copy across the source code

• Use SCCS to get every file out for editing and save it with the comment "RELEASE VERSION <n>"

• Copy across the user manual

• MOVE the scripts, library and pixmap directories from the "old" release folder to the new release folder

• Create symbolic link in the old release folder to the new one
• Copy across the DEMO folder

• Create a symbolic link in the new release folder called DEMO<n> that points to the DEMO folder

• Copy across the align program from the old release to the new release. This is needed for the initial compile run

You should have a look at the script before running it and see if you need to add/change anything to it.

To use it:

old_release!> /u/ccdev/script/NewRelease   <n>

where <n> is the new release number.

Update the version number

You will need to get /u/ccr.<n>/std/hdrs/release.h for editing

old_release!> get -e /u/ccr.<n>/std/hdrs/.sccs/s.release.h

Update the MAJOR RELEASE and MINOR_RELEASE definitions

[X11:old_release]!> vi release.h

Save the changes

[X11:old_release]!> delta /u/ccr.<n>/std/hdrs/.sccs/s.release.h

Compiling

Change to the new environment

[X11:old_release]!> gorel <n>
[X11:new_release]!>

Test that programs can be compiled

[X11:new_release]!> /u/ccr.<n>/script/buildall

Make sure you test for Text-mode and for X11.

Create symbolic links to programs

Create symbolic links to sieat, steat, etc. called ssieat, poeat, stestore, etc.

[X11:new_release]!> link_cntrl

Copy across test companies

[X11:new_release]!> cp -r /u/ccr.<n-1>/<TEST>/ /u/ccr.<n>/

Point ccdev to the new release

[X11:new_release]!> rm /u/ccdev
[X11:new_release]!> ln -s /u/ccr.<n> /u/ccdev

Copy Qt developer library files

The compiling script expects these folders to be in "/u/ccdev". This means we need to move them over to the new release directory when we change /u/ccdev to point to the new release. Need to create symlinks from old release to the new location.

[X11:new_release]!> cp -r /u/ccr.<n-1>/qtscox* /u/ccr.<n>/
[X11:new_release]!> cp -r /u/ccr.<n-1>/qtwin* /u/ccr.<n>/
[X11:new_release]!> cp -r /u/ccr.<n-1>/qtx11* /u/ccr.<n>/
[X11:new_release]!> ln -s /u/ccdev/qtscox* /u/ccr.>n-1>/
[X11:new_release]!> ln -s /u/ccdev/qtwin* /u/ccr.>n-1>/
[X11:new_release]!> ln -s /u/ccdev/qtx11* /u/ccr.>n-1>/

Setup Cron Jobs

Create script called /u/ccdev/binl/postr<n>. There should already be a similar script in cron. It should look like this:

export CCDIR=/u/ccr.<n>
export CCPROG=/u/ccr.<n>
/u/ccr.<n>/binl/auto_postal

Add it to cron along with compiling the old release

* 5-23 * * * /u/ccdev/binl/postr<n> > /u/ccr.<n>/LOG/auto_postal.out 2>&1
# Get latest source code of old release from SCCS
30 1 * * * /u/ccdev/script/RelCompile <n-1> /u/ccr.<n-1>/script/GetAll > /u/ccr.<n-1>/LOG/GetAll.out 2>&1
# Compile the code
10 2 * * * /u/ccdev/script/RelCompile <n-1> /u/ccr<n-1>/script/linux_build > /u/ccr.<n-1>/LOG/linux_build.out 2>&1