MKS Implementer 2006 Administration Guide

Chapter 3: Implementer Administration
70
System Control Maintenance Field Descriptions: Panel 3
Field Description
Activate issue object
stamping
Specify whether Implementer automatically stamps each object with the
issue or DR number the object is checked out with. To ensure stamping
of both new and existing objects, stamping occurs in the three stages
that allow object creation: check out, compile from the Workbench, and
promotion. For details, see page 145.
Y: Enables object stamping. When multiple locks exist with multiple
issues or DRs, the object is stamped with the primary number
associated with the initial lock.
N: Disables object stamping. This is the default value.
NOTE When MKS Integrity is the issue management system, this field name is
Activate issue object stamping. When DesignTracker is the issue management
system, the field name is Activate DR object stamping.
Activate object version
stamping
Assign native version
number at
Specify if Implementer automatically stamps each object, lock, and
repository record with a unique version number at defined stages within
the development cycle. For details, see page 146.
Y: Enables object version stamping. You must define the remaining
fields on this panel as described. This is the required value for the
Build List function to assign revision numbers to unstamped objects.
For details, see “Environment Repository Build” on page 117.
N: Disables object version stamping. This is the default value.
If the Activate object version stamping field is set to Y (active), specify
the versioning method.
1=checkout only:
Assigns the version number during check out. Implements a wholenumber
versioning scheme (no decimal). For example, checking out
version 2 of an object in production to a *TST environment increments
the version number to 3. Each new concurrent development lock
increments the version by 1 (for example, 4, 5, 6). When promoted
back to production, the version is set to that of the last *QAC object
version.
2=checkout and promotion to *PRD environments:
Assigns the version number in check out and promotion to *PRD
environments. Implements a decimal number versioning scheme
using both the left and right side of the decimal. For example, checking
out version 2.0 of an object in production to a *TST environment
increments the version number to 2.1. Each new concurrent
development lock increments the right side of the decimal by 1 (for
example, 2.2, 2.3, 2.4). When promoted back to production, the
version is set to 3.0 (the left side of the decimal is updated only when
promoted to production).
3=user defined:
Assigns the version number based on a custom, user-defined
versioning method. Requires a Versioning program name and Library
name as described next.