A development path is an identifier given to a new branch of software development. Changes made through the new development path are kept separate from the main development trunk unless you choose to merge them later.

For example, a user group at ABC Financial requests a special version of the stock calculator software. This group wants the commission fields removed and a special commissions legal message added. The task is assigned to Chad. He must use version 1.0 of the software because it did not contain commission fields. He must then add the new legal message to this version. He begins by creating a development path and a variant Sandbox from the checkpointed 1.0 version.

Once you have created a development path, you can open and work in a variant project by opening a variant Sandbox.

Windchill RV&S allows multiple developers to point to the same development path, each using their own variant Sandbox. In the variant Sandbox, you can see the current state of the project along the development path and the changes made by other developers using it.

When a development path is created for a project, by default it is also created for all subprojects. The assigned name is reserved as a unique identifier, ensuring no two paths can have the same name. The project is also automatically checkpointed when a development path is created.

You select the checkpoint from which to create a development path by selecting Pre-Defined Revision or Specific Revision. For Specific Revision, the most recent checkpoint is initially the default and shown in the parentheses to the right.

To choose the specific checkpoint from which to create the development path, you do one of the following:

The display to the right of Specific Revision is updated accordingly.

You can view the development path of a checkpoint, plus any development paths branched from a checkpoint in the Project History view. In this view, you select the checkpoint and view the details panel.

For Development Path Name, you enter a name for the new development path.

You specify the behavior to occur if a development path with the same name as an existing development path is created on a subproject in the target project. Typically, the default behavior is to use the existing development path in the subproject’s project, silently adding it into the new top-level development path. For On Existing Development Path, you can select from the following actions:

A project and its subprojects can be configured similarly or differently, depending on your software development needs. For example, a project and its subprojects may use the same main development path for a major release. In another example, a project and several of its subprojects may use a development path branched off the main development path for a service pack release. However, one subproject may be configured as a build subproject because it contains a set of shared libraries at a specific version that you do not want to change.

When creating a development path for a project, the default behavior is to create a new development path for the project and any subprojects that are configured the same as the parent project. For example, assume that a parent project and its subprojects are on either the mainline development path or a variant development path. A new development path is created for the parent project and its subprojects. This corresponds to setting Creation Method as Full and On Live Configuration to Retain the existing live configuration of the subproject.

If a project contains subprojects that are configured differently than the parent project, the default behavior is to retain the current configuration for those subprojects. Assume that a parent project contains one subproject that uses the same development path as the parent. However, it also contains another subproject that uses a different development path than the parent. A new development path is created for the parent and the subproject on the same development path as the parent. The subproject that uses a different development path than the parent remains untouched, retaining its existing development path.

During development, subprojects configured as normal or variant, also known as live (non-build) subprojects, might possibly need to change. Live subprojects might need to be on the same new development path as the parent project or be configured as build subprojects so that they remain at a specific version, based on the configuration as of the checkpoint from which the new development path is created.

For example, assume that you have a project that is on an existing development path. This project contains one subproject using the same development path and another subproject using a different development path. You can choose to create a new development path for the parent project and both subprojects.

Now assume that a parent project is on an existing development path. It contains one subproject that is on a different development path, and another subproject that is a build subproject. You can choose to create a new development path for the parent project and configure the existing variant subproject as a build subproject. The existing build subproject remains untouched.

To specify the way to create the development path, use the Creation Method option in the GUI. Select one of the following:

To specify how to treat live subprojects, use the On Live Configuration option in the GUI. Live configurations are subprojects that are configured to either normal or to a variant other than the variant you are creating. Select one of the following:

The Configuration Management Web interface uses the legacy option Resulting Subproject Configuration. Select one of the following: