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/junit5@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.

[marcphilipp]

Looks like all issues assigned to 4.13 have been resolved.

@junit-team/junit-committers Is there anything else that need to be addressed before releasing 4.13?

[kcooney]

@marcphilipp These closed pull requests might not be documented in the release notes: https://github.com/junit-team/junit4/issues?utf8=✓&q=label%3A"needs+release+notes+update"+

[stefanbirkner]

I started to complete the release notes. In doing so I created two new pull requests: #1551 and #1552. At least #1552 should be in 4.13.

[johnterrill]

Hello all,

I was wondering if anyone had a timeline for this release. There are some features that I was hoping to incorporate, and was wondering whether or not we should should table it.

Thanks for all your work!

[kcooney]

@johnterrill I don't think we were planning on adding any more new features to 4.13 (just bug fixes)

If there is something you want to add, please feel free to add a feature request. That being said, almost all feature development for JUnit is happening in the junit5 repository.

[Tibor17]

@kcooney If 4.13 contains only bug fixes, rename it to 4.12.1. Is there still any ongoing work?

[marcphilipp]

It's not onlt bug fixes, there's also a few new features, e.g. ordering. Thus, I think 4.13 make sense.

[stefanbirkner]

There are still 5 PRs missing in the release notes. I take care of them the day after tomorrow when I'm back in Germany. AFAIK this is all that is left.

[stefanbirkner]

@marcphilipp I think we are ready for JUnit 4.13. I completed the release notes.

Having #1568 released with JUnit 4.13 would be nice (need a review from one of the maintainers) but it is not necessary.

[robinyqiu]

Any update on 4.13 release? I am very excited to see the new release happens. :)

[Tibor17]

@robinyqiu
I remember they planned to discontinue JUnit and 4.13 had to be the last version. Since there are 103 open issues and several pending pull requests, the versions should continue development. One way would be to cut several Release Candidate versions and we will see what would happen with the statistics regarding the number of bugs and pull requests.

[kcooney]

I believe we still plan to release 4.13 (because of the sheer number of improvements and fixes that have been merged).

[kcooney]

Sorry, submitted that last comment before I finished my thought.

Apologies that this is taking awhile. The original JUnit maintainers are either busy supporting JUnit 5 or have taken a step back from working on JUnit. For those reasons I think it's likely that 4.13 will be the last release if the 4.x code line.

[sbrannen]

I'm taking care of the "deprecation messages" from Wednesday on.

If you get it done by Wednesday night, I might be able to include it in Spring Framework 5.2 GA, thereby allowing me to revert this commit spring-projects/spring-framework@665e8aa.

But... no pressure. Officially stating that Spring Framework 5.2 supports JUnit 4.13 is only nice-to-have. JUnit 4.13 will still work just fine with Spring 5.2 once JUnit 4.13 is released. 😉

[stefanbirkner]

Hi @sbrannen, I started but I don't get it done tonight. I'm currently reading all the comments and try to understand all the details.

[sbrannen]

@stefanbirkner, no worries! Like I said, that would have been "nice to have", but there's certainly no requirement for it. JUnit 4.13 still potentially has time to get picked up officially by Spring Boot 2.2. 😉

[sullis]

any thoughts about 4.13.0 GA?

[proski]

Without some resolution for #1609, JUnit 4.13 risks to be less relevant than it could be. Users of JUnit 4.12 are waiting for bugfixes and possibly some backports from JUnit 5, not for deprecation of the code that is not broken.

[sullis]

are there any blockers for JUnit 4.13 GA?

[marcphilipp]

I don't see any. I'll publish a 4.13-rc-1 to get some more feedback on the latest changes.

[marcphilipp]

JUnit 4.13-rc-1 is now available on Maven Central for testing! Please let us know if you run into any issues.

[razfriman]

Tested 4.13 beta and rc and works for us at our large org 👍

[sullis]

I tested JUnit 4.13-rc1 and I didn't encounter any issues.

[proski]

I tested JUnit 4.13-rc-1 with Stash Pull Request Builder plugin for Jenkins. Deprecations were triggered for files using ExpectedException once per file, as expected.

In many cases, the tests were checking the exception type, the message and the cause. I was able to fit all checks into one expression to avoid having a temporary variable.

I'm not getting any warnings or deprecations about the new code with SpotBugs, sb-contrib and find-sec-bugs.

The only small imperfection is that the coverage for assertThat is shown in yellow in Eclipse 2019-09 on Linux. Still much better than what is was before. Besides, nobody cares about test coverage of the tests themselves.

[sullis]

what is the status of JUnit 4.13?

[marcphilipp]

It's been three weeks now and only one issue has been reported: #1636

@kcooney @stefanbirkner Could you please take a look? I think we can close the above issue.

[kcooney]

@marcphilipp sorry for the long delay. I haven't had much time to work on JUnit for over a year.

I commented on that bug. I don't see how we can fix it.

I did have one feature request for 4.13. See #1637

[sullis]

Hi, what is the status of JUnit 4.13?

[marcphilipp]

#1637 was resolved and I'll release another RC.

[marcphilipp]

JUnit 4.13-rc-2 is now available on Maven Central for testing! Please let us know if you run into any issues.

[sullis]

I tested JUnit 4.13-rc2 and I didn't encounter any issues. LGTM

[proski]

Likewise, JUnit 4.13-rc-2 is working correctly for me. I'm using the new exception checks.

[sullis]

are there any blockers for JUnit 4.13 GA?

[marcphilipp]

@kcooney Could you please re-test with 4.13-rc-2 now that #1637 is resolved?

[sullis]

any update?

[sullis]

are there any blockers for JUnit 4.13 GA?

[kcooney]

Sorry for the late reply; things have been busy these last few weeks. I haven't had time to integrate the latest JUnit changes into our code repository. I did look at the tests on our side that cover the behavior of randomization when classes use FixMethodOrder, and they look almost exactly the same as the tests I had it my pull. I don't see a reason block a JUnit release on doing more verification on that fix.

[sullis]

q: are there any blockers for JUnit 4.13 GA?

[marcphilipp]

JUnit 4.13 is released! 🎊
https://twitter.com/junitteam/status/1212403812192964608