Problem

• A minor version is released that is bound to a specific Spring Boot version.
• When a new Spring Boot version is released, we provide compatibility with a patch release.
• A new Spring Boot minor or major version usually comes with the latest version of the AssertJ library
• When using camunda-bpm-assert or starter-test in combination with a newer Spring Boot version, this leads to version conflicts

Solution ideas

• Create a compatibility artifact for both camunda-bpm-assert and starter-test
  • Cons
    • More effort since we need to create, and test a compatibility artifact at two places; also, we have to maintain two compatibility matrices
• Create only one compatibility artifact for starter-test
  • Cons
    • In the past, this artifact was neglected and pointed to a very old version of camunda-bpm-assert; users need to learn or be pointed at that starter-test is the way to go in Spring Boot which creates friction
    • We break with the tradition to provide a compatibility artifact of camunda-bpm-assert
• Do nothing; a user can exclude and set the version of the AssertJ library explicitly
  • Cons
    • We don't have QA that ensures that camunda-bpm-assert is compatible with the respective version of the AssertJ library
    • This leads to confusion since we did provide a compatibility artifact in the past

Other thoughts

• The additionally supported Spring Boot version needs to be defined at a central place; the Spring Boot CI test profile should consume the centrally defined Spring Boot version.