The rollback section is especially important for event-driven systems. Imagine a Java 25 deployment starts publishing a new enum value to Kafka, then you roll the service back to Java 11 because of a runtime issue. The old consumer may fail to deserialize events that were already written, even though the old JAR itself is perfectly recoverable. I'd add a compatibility test that replays messages produced by both versions against both consumers before rollout. Rolling back binaries is one thing; rolling back the data contract is another.