I am working with EMC Documentum 6.6 using the DFS Java API. Currently I'm looking for a way to add and update symbolic labels to documents without interfering with system labels.
For my understanding, all labels (system labels and symbolic labels) are simply stored in the repeating-attribute r_version_label of documents. This means that when I create a new document without setting the r_version_label attribute at all, the server will automatically set the default system values 1,0 and CURRENT.
But as soon as I want to assign a symbolic label to the initial document version, I also have to take care of setting 1,0 and CURRENT, because the server will not set them automatically. Documents without the system labels are kind of broken, they can only be found via Webtop when searching for hidden objects and can also cause client-side errors when viewing their properties.
Another related problem might arise when building an interface for updating document attributes: The client-side developer would have to care of preventing users from modifying system labels and only let them add or remove symbolic labels.
I do understand that this behaviour can also be useful - for example, it would be possible to create a document starting with version 3.0, for whatever reason.
In my case, however, it would be easier to have the possibility to only work with the symbolic labels and leave management of the system labels completely to the server. Am I missing something?
EDIT: Seems like there is no other option than manually taking care of adding the required initial system-labels. I'll accept Chris' answer since he reconfirmed that.
The version service provides assistance for next minor / major numbering, but you must always explicitly set the CURRENT version label otherwise it will be missing.
versionService.checkout( toVersionIds, options );
DataPackage versioned = versionService.checkin( toVersion, VersionStrategy.NEXT_MINOR, false, Arrays.asList( new String[]{"CURRENT"} ), options );
This will implement the 1.0 -> 1.1 or with VersionStrategy.NEXT_MAJOR 1.0 -> 2.0