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:

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.

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