When your development team has largely finished a portion of a project and some project members are in a stable state, you can freeze individual members within a project or Sandbox.

Freezing a member places it in a state that prevents changes from being made to the member information that resides in the project file. For example, you cannot update the member revision or change the attributes of a frozen member. Freezing is the opposite of thawing a member.

Freezing restricts member information from being updated, preventing these members from being changed by accident. However, development work can still continue in the member file itself. For example, if new revisions are checked into the member’s archive, Windchill RV&S does not update the member revision for the project.

Freezing is useful for facilitating:

Freezing prevents changes to member information in the project, but does not affect the member file itself. Revisions can still be checked out, modified, and checked in, but none of the changes are included as part of the member information in the project.

You can change the label or state of frozen members, but not their attributes. Freezing can be used immediately before a checkpoint operation to ensure no one changes the project or its members before the checkpoint is complete.

When you want to allow project members to be changed, you can thaw them.

If a member is frozen, Windchill RV&S reports the availability of new revisions when anyone checks them into the archive. Windchill RV&S does not update the project to the latest revision, so an appropriate person must make the decision to thaw the member and update the project as a whole.

A sample freezing sequence is as follows: