Simulation DSL source compatibility ends at the Gatling 2.x to 3.x boundary

Gatling 3.x is not source-compatible with the 2.x simulation DSL, which turns a move between the two major versions into a manual migration rather than a drop-in upgrade. HTTP protocol setup, request chaining, and injection profiles written for 2.x do not compile unchanged under 3.x.

Since simulations are compiled Scala classes that the runner loads from the simulations directory, the change happens at compile time rather than through a runtime configuration switch. The unresolved part is scope: exact DSL method names vary across 3.x minor releases, and Maven or Gradle Gatling plugins can override default directories and simulation arguments, so the pinned target version and the build configuration together determine how much code must change. Each run also writes its own timestamped results directory, which complicates before-and-after comparisons once the migrated code compiles.

• Which DSL areas of a 2.x simulation must be rewritten by hand for 3.x, and does Gatling offer an official migration aid rather than a compatibility layer?
• How should behavioral parity between the original and migrated simulation be verified, given version-specific method differences and separate per-run results folders?
• Is pinning the migration to one specific 3.x minor release the safest way to avoid repeated rewrites?