Release properties

A meaningless ID that serves to identify release versions uniquely and is generated by Delivery Manager.

The folder path that identifies the root folder as seen from the machine(s) that you deliver from.

You can refer to this folder path by using the ${root} source variable.

The name of the current release version,which is automatically also the name of the current version of the top-level application. When you call a release action, this will cause deliverables to be included in this version. This happens by placing the deliverables in the release folder on the file system (see also the "Release folder" property below).

The name of the most recent previous release version (if any), which is automatically also the name of the most recent previous version of the top-level application and the name of the previous release folder.

This property is used for comparison purposes. When you call an action that releases data (metadata, authdata or appdata), Delivery Manager attempts to perform a data comparison and writes the result to a file containing "diff" in its name. This allows you to see the differences with the same file in the previous version. If the previous version was the initial version, comparison is with an empty set. The result of such a comparison is that all data currently present are data added in the current release.

You can revert to the previous release version.

You can refer to the subfolder of the root folder that has the previous release version name by using the ${previous} source variable.

The folder path leading from the machine(s) from which you deliver to the folder where deliverables are currently written to. "Release folder" is the combination of "Root folder" and "Release version". If "Root folder" is :

\\fs\Releases\TRAVEL 

and "Application version" is :

1.0

Then "Release folder" is :

\\fs\Releases\TRAVEL\1.0

You can refer to "Release folder" by using the ${release} source variable.

The date and time when the current release was created.

The date and time when Delivery Manager last wrote deliverables to the current release folder through the execution of a release action.

An indicator that the release is the current release and that its release folder is the folder where deliverables are currently written to. Exactly 1 release known to Delivery Manager has Current = Yes at any one time.

An indicator that the release is the first release in the current release tree. Exactly 1 release known to Delivery Manager has Initial = Yes at any one time. If the current release is the initial release, when performing comparison actions, Delivery Manager knows not to expect a previous version of data and performs a comparison with an empty set of data instead. The result of such a comparison is all data currently present: all this data is considered to have been "added" in the initial release.

If this indicator is set to Yes, the XML document in the Registries window (choose Define, Registries from the menu) that has Current = Yes (if any) is writtten to the release folder as a file named "registry.xml", overwriting any other file by that name in that folder.

If this indicator is set to Yes, attachments are written to sections of the current release folder if you have defined attachments for that section and whenever you release deliverables to that section.

If this indicator is set to No, attachments are NOT output for any of the sections.

If this indicator is set to No (the default), when you transition to the next release, NO deliverables are automatically copied to the new release folder.

If this indicator is set to Yes, when you transition to the next release, all the deliverables of the current release are automatically copied to the new release folder as a starting set of deliverables, with the exception of deliverables that are release-specific by definition:

•The \scripts section

•Files in the \metadata section that have "diff" or "initial" in their name

•Files in the \appdata section that have "diff" or "initial" in their name

Also, any files and folders that are blocked for the release (as explained in the sections below) are excluded from the copy operation.

Setting "Copy deliverables to next release" = Yes is attractive if you want to see a complete set of deliverables in the current release folder at all times.

Setting "Copy deliverables to next release" = No is attractive when you release often and you do not want large volumes of data to be copied to each new release folder. It is also attractive if you have releases that differ only slightly from the previous release, and you want to see at a glance where the differences are by only having the differing deliverables in the new release folder. The drawback of this way of working is that a release folder distributed on a target machine does not contain all the deliverables. If you work in this way with multiple subsequent releases, it becomes increasingly unclear for operators on target machines to know what actions to perform in order to assemble a correct and complete set of deliverables.

This list of relative filepaths has an effect only if you set "Copy deliverables to next release" = Yes. Files placed in this list and that have Blocked = Yes are NOT copied automatically to the new release folder when you transition to a new release. Make sure each entry is a relative path leading from the release folder to an individual file. Entries that do not meet this condition are ignored. Make sure each entry starts with a single backslash ( \ ).

This list of relative folderpaths has an effect only if you set "Copy deliverables to next release" = Yes. Folders placed in this list and that have Blocked = Yes are NOT copied automatically to the new release folder when you transition to a new release. Make sure each entry is a relative path leading from the release folder to an individual folder. Entries that do not meet this condition are ignored. Make sure each entry starts with a single backslash ( \ ).

A standard version of the document named "packing-slip.xml" that is output to the release folder if you have set "Include packing slip" = Yes.

•If you leave "Packing slip XSL" empty, then "Packing slip base" equals "Packing slip output" and shows the document that is output.

•If you specify a value for "Packing slip XSL", "Packing slip base" shows the document that the XSL transformation is applied to. "Packing slip output" shows the result.

"Packing slip base" is updated :

•When you run a task step that executes a "Release..." action.

•When you press the Refresh button on the "Packing slip" tab of the Current Release window.

An optional reference to an XSL transformation stored in Delivery Manager as custom XSL.

This field allows you to tailor the contents of the "Packing slip base" document to your needs.

If you specify "Packing slip XSL", each time you run a task step that executes a "Release..." action, and each time you press the Refresh button on the "Packing slip" tab of the Current Release window, the referenced XSL transformation is applied to "Packing slip base" just before the document is actually released.

In the "Packing slip output" field, you can view the result of the transformation.

The document named "packing-slip.xml" that is output to the release folder if you have set "Include packing slip" = Yes.

"Packing slip output" is updated :

•When you run a task step that executes a "Release..." action.

•When you press the Refresh button on the "Packing slip" tab of the Current Release window.

If this indicator is set to Yes, the XML document shown in the "Packing slip output" field is written to the current release folder when you run any release task.

If this indicator is set to No, there will be no "packing-slip.xml" document in the release folder after you run a release task.