Preparing an Application for Release
Preparing a module for release involves:
Caution: Before you prepare your application for release, make a copy of the source code in a release directory. You will prepare the copy of the source code as the released application. Do not add proprietary restrictions or text strip your source files.
Adding Version Information
G2 Foundation Resources (GFR) provides utilities for specifying and validating the version dependencies between modules and between the module and G2. The version checking system warns the user when an incompatible set of modules is loaded and also dispatches user-defined upgrade procedures when a new version of a supporting module is loaded. Before you release your application, you should ensure that it contains a version information object, which keeps track of all version information in the application.
For more information, see the G2 Foundation Resources User's Guide.
Protecting Your KB
You have several reasons for protecting your KB, either by text stripping or by proprietary restrictions, or both:
Caution: Never text strip your source code or make your source code proprietary. You should only perform these actions on copies of the source code.
Adding Proprietary Packages to Workspaces
You can add proprietary restrictions to workspaces to make them private. Workspaces inherit their proprietary restrictions from their superior workspace.
To make workspaces proprietary:
- Enter package proprietary mode by choosing
Main Menu > Miscellany > Enter Package Preparation Mode.
- Edit the
Proprietary-package attribute of workspaces you want to be proprietary.
The options are:
If you want to require new authorization codes at each major release, change the package name. For example, when GDA version 3 was released, the package name was changed from gensym-gda2 to gensym-gda3.
Caution: If the proprietary package of a workspace is none, the workspace inherits its proprietary status from the superior item. Do not be confused by thinking none means the workspace is not proprietary.
Adding User Interface Configurations
You can add user interface configurations to individual items to control various features of the item, including the visible attributes and menu choices, selection behavior, and network access. You can specify proprietary configurations on instances of classes, on individual items, such as workspaces, or on the overall knowledge base.
In general, you should avoid using item configurations to specify restrictions on items such as workspaces, except to restrict user access or to define special-purpose workspaces.
To configure the behavior of instances of a class:
To configure the behavior of items:
Here are some general guidelines:
For more information on using user interface configurations, see Using Configurations and User Modes to Enforce Encapsulation.
For more information on specifying user modes, see Avoiding User Mode Conflicts in Modules.
Adding Text Stripping to Your KB
You can add text stripping to your KB so that users will not be able to read the text of procedures, methods, rules, and functions. The main purpose of text stripping is to protect your intellectual property.
Because text stripping follows the workspace hierarchy, the best strategy is to mark workspaces for text stripping at the highest possible level and remove text strip marks by exception. You should always text strip private procedures. You should not text strip user interface texts, such as those on palettes and master dialogs.
To text strip your application:
Caution: If you distribute a text-stripped KB that uses inlining and stability declarations and you distribute an upgraded KB, the user of the KB will not be able to run the KB. For this reason, we recommend that you declare only private items to use inlining and stability declarations when you release your application.
Creating a Release Manager Module
Preparing a module for release involves a sequence of steps that have profound, global effects on the source code. Because of the sensitivity of these steps, the amount of manual effort potentially involved, and the repetitive nature of the tasks, we recommend that you automate the release process as much as possible to reduce the chance of last-minute error.
We recommend keeping the code for automating the release process in a release manager module. This module should require all modules involved in the release. The release manager module should contain a checklist for all the steps involved with transforming the source code into shippable distribution code. If possible, you should perform these steps programmatically through a series of action buttons.
Typical steps in preparing a module for release include:
- Setting the version information for the release throughout the KB.
- Setting up the system tables in each module, initial user mode, and run options.
- Hiding the name boxes and attribute displays on all non-visible items, which you can do programmatically by using the attribute access facility.
- Clearing the
Authors and Change-log attributes of all procedures, definitions, and relations. You can do this programmatically by changing the text of the attribute to "" (the empty string).
- Deleting any extraneous modules that are strictly for development, such as developer tools.
- Deleting all unnecessary workspaces, dialog copies, testing workspaces, and so on, that you might have generated during the development process.
By taking these steps, you typically reduce the size of your KB by 50% or more. This not only saves memory but it also significantly decreases the time needed for loading the KB.
Carrying out the Release Process
Once you have created and tested your release manager module, preparing your KB for release is straightforward.
To carry out the actual release:
- Make sure all developers have checked in their latest sources, then copy the sources into a separate release preparation area.
- Load the release manager module, which should load as dependent modules all modules included in the release.
If there are conflicts, incomplete items, or items with notes, you are not ready for release. You must correct these problems in the source code.
- Execute the checklist in the release manager module.
- Save the "clean" source code to the source branch of the release directory.
Caution: Do not save it back to the /product/sources directory.
- Choose
Main Menu > Miscellany > Strip Texts Now to text strip the KB.
- Choose
Main Menu > Miscellany > Make Workspaces Proprietary Now to make workspaces proprietary.
- Save the code to the distribution branch of the release directory.
- Run all automated and manual tests.
Copyright © 1997 Gensym Corporation, Inc.
Specify the