Managing a Version-Controlled Environment
In Loftware Enterprise™ SP, you can use to retain multiple versions of and to roll back to a previous version if necessary. In a multi-user environment, you can use version control to help ensure that users do not accidentally overwrite each other's work.
Commands related to version control are available in Access Control 
, Label Design 
, Application Design 
, Process Design 
, and Data Services 
. Additionally, users with the necessary permissions can enter a specific version to print in Print 
.
Implementing version control
Version control is managed at the folder level and applies to every object in the folder. Version control can be enabled or disabled only during the creation of a folder. After you have saved a new folder, you can no longer change the version control setting for it. However, you can convert existing objects to version-controlled objects by moving them into new folders for which version control is turned on. For more information, see Turn on Version Control.
Note: If you save a copy of a version-controlled object into a different folder, the version control history and the Default Permissions are not propagated to the new instance.
Separating development and production areas
You can maintain separate folders within the same Loftware Enterprise SP instance for label templates that are under development and label templates that have been published to production, or for any situation in which label templates are edited in one folder and then moved to another. For example, this approach allows you to create a Development folder accessible to users with the role and a Production folder for released label templates that they cannot modify. Administrators copy label templates from the Development folder and publish them to the production folder.
Tip: If your organization has separate Loftware Application Servers for different phases of development (such as development, quality assurance, user acceptance testing, and production), can provide administrators with an efficient means transferring objects from one phase to another. For more information, see Performing Object Promotion.
Important! If label templates are typically copied from one folder to another, it is recommended that layouts and label templates be saved in separate folders to prevent confusion. If associated layouts and label templates are mingled in the same folder, when you copy all items in the folder to a second folder, label templates in the second folder are still associated with the layouts in the original folder.
Note: By default, users who have only the role do not have Publish permission for Documents and must request that a publish label templates to the production area.
Granting the permissions needed to support version control
By default, the role is granted all role-based permissions related to version control, including Publish permissions for Documents, Catalogs, Processes, and Data Services.
The role is granted the permissions needed to create, save, check in, check out, and undo check out, as well as the permissions necessary to view and print current and previous published versions and minor versions of objects managed by using Documents permissions. The role is granted the permission to publish objects managed by using Documents permissions. The role (intended for a ) is granted the permissions needed to print the most recently published version. For more information, see Permissions for Version-Controlled Objects.
Recognizing version-controlled items
Version-controlled folders are identified in console trees where they appear by the icon 
.
In Access Control , any version-controlled object includes Version Info 
on the View tab in the ribbon. For any folder, the Properties pane displays the Version Control status of the folder.
Understanding version numbers
A major.minor numbering scheme is used to differentiate between published versions (major versions) and minor versions of an object. Images have only published versions. Layouts must be published before they are available for attachment to a label template.
The first time that an object is checked out, the Version is 0.1. The minor version is incremented each time that a user checks out the object. Merely saving a version-controlled object does not change its version.
When an object is published, its major version number is incremented and its minor version number is set to zero. For example, if you have a label template with a version of 1.3, publishing that label template creates a version 2.0.
Printing and version control
By default, the latest available version of a version-controlled object is selected when a user prints an object. However, the versions available for the user to print can be limited by the user's permissions. If the user has Design Print permissions for Documents and for Device Groups and Write permission for Documents (both as role-based permissions and object access permissions), then the user can print any or minor version except a version that is checked out to another user. Otherwise, the user can print only the latest published version.
A typically has only the permissions necessary to view and print published versions. For a Data Provider, the latest version is the latest published version.
If you are maintaining separate development and production areas, you can ensure that minor versions of objects in the production folder are not printed by denying Design Print permissions to the production folder.
Note: You must publish a field data catalog before it can be attached to a label template. You can attach a version-controlled layout to a label template before the layout is published; however, you must publish a version-controlled layout before printing a label template containing the layout or the print job will fail.
Checking in or rolling back a version
A checked-in version cannot be altered. The most recently can be rolled back and deleted if no minor version has been checked in after that published version. If the most recently published version is immediately preceded by other published versions, they can also be rolled back and deleted. Other than those exceptions, although an entire object can be deleted, individual versions of it cannot be deleted separately. For more information, see Roll Back to a Previous Version.
As an administrator, you can take control of a version that another user has checked out, after which you can undo their changes if necessary and then check it in. For more information, see Take Control of a Version-Controlled Object.
Important! If you are using , it is recommended that you use a to collectively publish or roll back promoted objects rather than managing those objects individually. If you have resorted to individually publishing or rolling back promoted objects, additional follow up may be necessary. For more information, see Respond to a Promotion Result.
Checking out before making changes
As an administrator, before you can change the name or description of a version-controlled object, you must check it out. Afterward, you must check in the object so that other users can make changes to it.
Before a user begins making changes to a version-controlled object, the user should check it out so that he or she will be able to save and check in changes when finished. Checking out an object also prevents other users from making changes to it at the same time. If a user does not check out a version-controlled object before changing it, that user must save his or her changes to a new object to retain them. Otherwise, the changes will be discarded when the object is checked out.
Note: Each version of an object can have different tags applied.