Deployment Script Dependency Versions Ignored

I am trying to update a project where a deployment script is dependent on Security package version 5.3.1 (before IsInitalScreen database field was introduced).

Anyway the whole Security deployment is performed until version 5.4 so all my scripts which did not include this field fail.

This was exactly the reason to introduce package version dependencies on the deployment scripts, so deployments would be ordered in the way they were introduced in between package version switches.

  <dv:DeploymentVersion
    asi:abstract="false"
    dv:deploymentDependenciesCsv="&#xD;&#xA;147fa70d-6519-4393-b5d0-87931f9fd609, 5.1.8&#xD;&#xA;951f2cda-2867-4b99-8824-071fa8749ead, 5.3.1&#xD;&#xA;b9ab12fe-7f7d-43f7-bedc-93747647d6e4, 1.2.3&#xD;&#xA;de1b2a3c-2d03-49ce-ba0d-5e44972daf1f, 1.0.0&#xD;&#xA;255eec22-89c5-479a-b48d-e7bc9baa564a, 1.0.0"

This script even when dependent on Security 5.3.1 is executed after Security is updated to 5.3.2.

What happens when:

  1. We use a typical root model (root, security, menu)
  2. Audit package (also a part of our root model distribution) is NOT used at the moment, so no scripts are being executed
  3. Later on the developer decides to include the Audit package

Now all the Audit scripts will have to run but they are dependent on different versions of Root model, as it was developed.

Will it run?

This was discusewd on the weekly meating. If the Architect detects the situation when there is a new package in the model it will offer the user an option to run the deployment scripts of this package without any dependency checks. If the deploymnet scripts fail, the user will have to figure out where the problem is an tweak the scripts.

Note: This should only be a problem for the developer in Architect right after adding a package because old scripts already ran. It would not be a problem when creating a new database as the scripts would run in the correct order. The solution is to “try” to run the scripts without dependency checks (but they may fail as some old scripts could depend on database structures that no longer exist). If this does not work, the best would be to just create a database from scratch or to fix the scripts in the way that they would run well.