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 path 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 path 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 path variable.

A folder path identifying the temp folder used by Delivery Manager for storing intermediate results on the file system during processing. As long as processing is successful, these intermediate results are irrelevant. Otherwise, they may be helpful for debugging.

Because "Temp folder" is a release property, it is the same for all machines from which you deliver:

•If it contains a filepath to a local folder, each machine will write to its own physical temp folder.

•If it contains a filepath to a shared folder, all machines will write to the same physical temp folder.

You can refer to "Temp folder" by using the $$temp path variable.

A folder path identifying the stash folder used by Delivery Manager for storing data temporarily when it executes upgrade scripts that are part of a release. This data is only relevant whilst the upgrade scripts run, but is not automatically removed afterwards.

Because "Stash folder" is a release property, it is the same for all machines from which you deliver:

•If it contains a filepath to a local folder, each machine will write to its own physical stash folder.

•If it contains a filepath to a shared folder, all machines will write to the same physical stash folder.

You can refer to "Stash folder" by using the $$stash path 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.

An XML document listing all application names in scope for the release with, for each application,

•the version that the application is currently in,

•the USoft version of the USoft tooling used to develop the application in Development.

This XML document is written to the release tree if you have set "Include packing slip" = Yes.

If this indicator is set to Yes, the XML document shown as the "Packing slip" release property is written to the current release folder whenever you release deliverables to it.

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 ( \ ).