Review Hints:

• rename folder from test-schema-with-old-engine to test-old-engine to align with other directories
• rename artifact from camunda-new-schema-old-engine to camunda-qa-old-engine to align with other projects
• we do not need to test the database upgrade in this suite as this is already verified by the db-upgrade test, instead test following:
  1. unpack the current sql scripts
  2. drop database if present
  3. create new schema
  4. run old test suite with old engine
  5. drop database
• currently the versions of all test dependencies like h2, junit etc are the ones from the current/new engine, instead the versions from the old engine test suite should be used
• currently the old version is explicitly overridden to 7.5.3-ee if this should always be the latest version for the previous camunda version than a task for updating it has to be added to the wiki page of a patch release: https://github.com/camunda/camunda-bpm-platform/wiki/Perfoming-a-Patch-Release

Is it possible that we break the rolling upgrade from 7.5.x to 7.6.0 on the 7.5 branch? If so we maybe check the upgrade against the 7.5.x-SNAPSHOT version to detect such a problem before we release the 7.5.x version. If not the latest 7.5.x release should be okay.

Hey sebastian.menski,

I think, theoretically it is not possible to break the test suite if changes are done on the older branch.
Changes which are done on the older branch are also done on master (Bug fixes for example).
I'm not quite sure if we need to update the version on a patch release. What do you think?

Greets,
Chris

• the release test is broken: https://ci.camunda.com/jenkins/release/job/7.6/job/7.6-TEST-RELEASE-camunda-bpm/76/console
• why do we need the property camunda.version.current? Its the same as project.version
• why do we need to parse the project versions? The results are never used.
• Please adjust this execution id as it does not unpacks old scripts