Now that the first stable release is out, we need to ensure that subsequent releases are sufficiently backwards compatible. To help ensure backwards compatibility across releases, we should add upgrade tests. An example of what this might look like:
Create a database using the v1.0.0 libraries
Populate the v1.0.0 database with a mix of orchestrations, some completed, some running and waiting for events, and some pending (using scheduled start times).
Backup the database and check it into the Git repository
Create a test (or tests) in the vCurrent code that restore the v1.0.0 database, followed by;
Going through the normal app startup flow, which should auto-update the schema
Allow pending instances to start normally
Create new instances using the new instances
Resume existing instances
Query for all instances, old and new, asserting that all expected properties are available.
This should give us a good sense about whether any given PR is sufficiently backwards compatible with earlier database versions.
As we release new versions, we can add new tests that do the same thing, but starting from different previously released versions. For example, a v4 release could include tests that validate upgrades from v1 to v4, v2 to v4, and v3 to v4.
Ideally, we have a new upgrade test for every minor release (minor releases typically contain new features). New tests shouldn't be necessary for patch releases.
Now that the first stable release is out, we need to ensure that subsequent releases are sufficiently backwards compatible. To help ensure backwards compatibility across releases, we should add upgrade tests. An example of what this might look like:
This should give us a good sense about whether any given PR is sufficiently backwards compatible with earlier database versions.
As we release new versions, we can add new tests that do the same thing, but starting from different previously released versions. For example, a v4 release could include tests that validate upgrades from v1 to v4, v2 to v4, and v3 to v4.
Ideally, we have a new upgrade test for every minor release (minor releases typically contain new features). New tests shouldn't be necessary for patch releases.