[ This issue was auto-migrated from DA's internal repo (DACH-NY/canton-network-node#19814). Original author: @moritzkiefer-da ]

Daml upgrading requires that clients do not:

1. Exercise choices before the corresponding versions are vetted.
2. Set new optional fields to Some before the corresponding versions are vetted.

This is accomplished through the feature support endpoint to first check the version client side.

However, it is very easy to forget to add such a check when you write code and then code might blow up until the new versions are vetted. Sometimes ciupgrade/ciperiodic help to catch them but it is unrealistic to test everything there. We also have select integration tests but you're obviously not gonna write one if you forget about the check being needed.

The best option I can come up with is that we have a dedicated job (run e.g. daily but we can debate frequency, should definitely be possible to run it on a PR on demand ofc) that runs all integration tests but sets the initial package version to the one from the latest release instead of the current one.

We generally test all functionality in integration tests so this gives us pretty decent coverage.

To make this work in practice, I would imagine:

1. The CI job sets an environment variable (or several) to switch to the old versions.
2. We pick that up in the environment setup and use it to change SV1's initial package config to the latest DARs in the LATEST_RELEASE version.
3. We add scalatest tags to fully exclude some tests, e.g., the BoostrapPackageConfigTest makes no sense to run here.
4. We add scalatest tags like Amulet_0_1_8, DsoGovernance_0_1_12. Tests that should only run with versions >= those are tagged like this. The CI job then excludes tests with tags that have versions higher than what is in LATEST_RELEASE.