Update release notes

Author: kcooney

doc/ReleaseNotes4.13.2.md

@@ -11,3 +11,20 @@ people reported problems that were caused by explicitly destroying the `ThreadGr
 
 In this change, the code was updated to call  `ThreadGroup.setDaemon(true)` instead of destroying the
 ThreadGroup.
+
+### [Pull request $1691:](https://github.com/junit-team/junit/pull/1691) Only create ThreadGroups if FailOnTimeout.lookForStuckThread is true.
+
+In JUnit 4.12 ([pull request #742](https://github.com/junit-team/junit4/pull/742)) the `Timeout`
+Rule was updated to optionally display the stacktrace of the thread that appears to be stuck
+(enabled on an opt-in basis by passing `true` to `Timeout.Builder.lookForStuckThread(boolean)`).
+When that change was made, time-limited tests were changed to start the new thread in a new
+`ThreadGroup`, even if the test did not call `lookForStuckThread()`. This subtle change in
+behavior resulted in visible behavior changes to some tests (for example, tests of code that uses
+`java.beans.ThreadGroupContext`).
+
+In this change, the code is updated to only create a new `ThreadGroup` if the caller calls
+`Timeout.Builder.lookForStuckThread(true)`. Tests with timeouts that do not make this call will
+behave as they did in JUnit 4.11 (and more similar to tests that do not have a timeout). This
+unfortunately could result in visible changes of tests written or updated since the 4.12
+release. If this change adversely affects your tests, you can create the `Timeout` rule via the
+builder and call `Timeout.Builder.lookForStuckThread(true)`.