Hi Stephane, We are talking only about these two commits [1]? Notice that 001e807 modifies file names to the verbose one which breaks backwards compatibility and this should not forcibly (by default) happen in your version/branch. Try to fork the project, make a local branch and then reset HEAD to [2], i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3 And then cherrypick both commits [1]. Make sure the order is correct but it won't be so straightforward. The tests have to pass (mvn install -P run-its).
[1]: https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9 https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a [2]: https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3 Cheers Tibor On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <stephane.nic...@gmail.com> wrote: > Hi everyone, > > It's great to see the progress on Surefire 3.0 and I wanted to reach out to > discuss a practicable problem with the 2.x line. There are a number of > fixes for JUnit 5 that are only available in the 3.x line that isn't GA > yet. [1][2] > > Putting my Spring Boot hat for a min, this actually prevents us from > upgrading our test support to JUnit 5: our plan is to offer maximum > flexibility by providing the vintage engine (so that users can keep their > tests and migrate at their own pace). > > We can't upgrade to a milestone as our upgrade policy prevents that > (regardless of how stable this is and especially since backward > incompatible changes have been pushed to the latest milestone). So we're > kind of stuck. > > Would there be an appetite to backport those fixes and release a 2.22.2? > > Thanks, > S. > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614 > [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546 >
