Release JUnit 4.13

[kcooney]

This issue tracks the work needed to release JUnit 4.13

[kcooney]

@junit-team/junit-committers any thoughts on a 4.13 release? I have unfortunately been very busy with my day job so I can't drive a 4.13 release, but I can certainly help.

I've associated some open issues with Milestone 4.13 as a starting point, but it appears that milestones cannot have comment threads, so I figured we can discuss scheduling and which features should be included here

[marcphilipp]

One thing I would like to do is aligning Assert.assertThrows/expectThrows with Jupiter's Assertions.assertThrows. I know there was some controversy around that a while back but now that Jupiter's been released I think we should consider migration scenarios and remove Assert.assertThrows and rename expectThrows to assertThrows. Any objections?

[panchenko]

The last attempt to remove one of those was #1396

[kcooney]

I can see both sides of the debate about merging assertThrows and expectThrows, so I wouldn't object to a pull removing expectThrows and updating assertThrows to return the caught exception. I suggest reaching out the people involved in the original pull adding these methods to 4.x, to inform them of the resolution of this issue. I realize some people would have been upset regardless of what direction we decided to take with the APIs, but still think that it's good to make sure everyone knows their voice is being heard.

While we are at it, it would be great to port assertThrows(Class<T> expectedType, Executable executable, String message) to JUnit4 (see junit-team/junit-framework@ea67ca0)

[zjffdu]

any progress on 4.13 release ?

[kcooney]

@zjffdu yes. See https://github.com/junit-team/junit4/pulse/monthly for recent work and https://github.com/junit-team/junit4/milestone/3 for the proposed remaining work.

[Tibor17]

@kcooney
@marcphilipp
It's been almost 4 years after last release 4.12.
Cut 4.13-beta-1 release version for deeper testing.

[cljohnso]

I (my organization, really) would really like to use the work that was done for TemporaryFolder (particularly issue #1223) so I'm really interested in getting JUnit 4.13. We're contemplating taking a fork of the project (at 4.12), cherry-picking the TemporaryFolder fixes, and using JUnit artifacts generated from that until 4.13 is actually released. (Haven't yet evaluated how sane/insane that is.) Since at least some of the projects in which we'd be using the fork are public/OSS projects, the artifacts produced from the fork will need to be published (under a Maven group we own) to Maven Central. But, if you're planning on cutting 4.13 anytime soon, we can just wait. (We do have efforts underway to migrate to JUnit 5 but that doesn't help us yet with TemporaryFolder.)

Thoughts?

[aiannucci]

We have built and use 4.13 as it is, with all its changes, for a while now, because we needed to leverage a bugfix. Haven't seen any issues so far.

[kcooney]

@cljohnso publishing your own version of JUnit in Maven could be problematic for some of your users because they will likely depend on an official version of JUnit, and having both dependencies would result in duplicate classes on the classpath, which leads to unpredictable behavior.

Unfortunately, JUnit is maintained by volunteers (many of whom work on JUnit 5) so relesses have taken longer than anticipated.

One way to help us get ready would be to fix and review the release notes. Many pull requests were not documented there (see these bugs).

The blocking bugs for 4.13 are here.