Changeset Versioning: version and versionStrategy

Changeset Versioning is only for "rerunnable" stored logic scripts (where rerunnable=true is the default behavior or has been set in the metadata.properties file):

• function folder or packageMethod=STOREDLOGIC
• package folder or packageMethod=STOREDLOGIC
• packageBody folder or packageMethod=STOREDLOGIC
• procedure folder or packageMethod=STOREDLOGIC
• trigger folder or packageMethod=STOREDLOGIC
• view folder or packageMethod=STOREDLOGIC

Do NOT use ignore/unignore or cleanup/replace with stored logic scripts that are packaged in those folders.  Only use the versioning with stored logic in those folders.

During packaging, the following attributes are set:

• datical:origFilePath
• datical:origFileName
• datical:version
• datical:versionStrategy

The packaging process checks to see if changesets using origFilePath and orgFileName have been deployed before. 

If so, the datical:version is incremented. 

For stored-logic changes (function, procedure, package, packagebody, trigger, view), the packaging process leaves the files in the directory rather than archive them. 

Simply fix your stored logic script and check the modified sql script into your SQL repository.  This will trigger a Datical packaging build job and the updated script will get packaged and available to be deployed. 

• Since the script was previously packaged, Datical increments the version in its changeset. 
  • For example: The first time you commit a stored logic sql script, packager will add a changeset with datical:version="1" to the changelog.xml.  Then after you modify the same stored logic script and commit it again, packager will add a changeset with datical:version="2" to the changelog.xml.  New changesets with higher versions will be created each time the stored logic script is modified and committed.
• In case of reverting stored logic to previous version, you will end up creating a new changeset version with same logic from previous version.
  • For example: Previously the highest changeset for this stored logic object was version 5.  Now you would like to revert back to using what you had before as version 3 of that change set.  Modify the script in your sql repository to have the same contents as it had back when you were on version 3.  Commit the modified script.  Packager will add a new changeset with datical:version="6" to the changelog.xml.  The contents of the new version 6 can be the same as an older version of the script, but a new higher versioned change set will be created.  Change set version numbers increment higher with each iteration.

Use the versionStrategy variable in a metadata.properties file to specify deployment behavior when multiple versions are available:

• deployAll - deploy all versions found (default)
• deployLatest - deploy only the latest version

The datical:versionStrategy changeset attribute takes its value from this setting. 

By default Datical will deploy all versions of the changeset to the target environment, but that can be changed.

• For example, if a specific stored logic change was never deployed to the STAGE environment, then Datical will deploy all versions of the changeset (from oldest to newest) to STAGE.
• If you prefer to only deploy the latest/newest/highest version of stored logic change sets, then you will need to specify versionStrategy=deployLatest in the metadata.properties files for your stored logic folders.  Then only the newest version of a stored logic changeset will be deployed.  

See Using the metadata.properties file.