<commit_before>## Summary of changes in version 4.13.2

# Rules

### [Pull request #1687:](https://github.com/junit-team/junit/pull/1687) Mark ThreadGroups created by FailOnTimeout as daemon groups

In JUnit 4.13 ([pull request #1517](https://github.com/junit-team/junit4/pull/1517)) an attempt was
made to fix leakage of the `ThreadGroup` instances created when a test is run with a timeout. That
change explicitly destroyed the `ThreadGroup` that was created for the time-limited test. Numerous
people reported problems that were caused by explicitly destroying the `ThreadGroup`.

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)`.<commit_msg>Update 4.13.2 release notes to document pull 1654<commit_after>## Summary of changes in version 4.13.2

# Rules

### [Pull request #1687:](https://github.com/junit-team/junit/pull/1687) Mark ThreadGroups created by FailOnTimeout as daemon groups

In JUnit 4.13 ([pull request #1517](https://github.com/junit-team/junit4/pull/1517)) an attempt was
made to fix leakage of the `ThreadGroup` instances created when a test is run with a timeout. That
change explicitly destroyed the `ThreadGroup` that was created for the time-limited test. Numerous
people reported problems that were caused by explicitly destroying the `ThreadGroup`.

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)`.

# Exceptions

### [Pull request #1654:](https://github.com/junit-team/junit/pull/1654) Fix for issue #1192: NotSerializableException with AssumptionViolatedException

This change fixes an issue where `AssumptionViolatedException` instances could not be serialized
if they were created with a constructor that takes in an `org.hamcrest.Matcher` instance (these
constructors are used if you use one of the `assumeThat()` methods in `org.junit.Assume`).
{'fraction_non_alphanumeric': 0.07851054284432481, 'fraction_numerical': 0.02602063705697622, 'mean_word_length': 5.042005420054201, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 9, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6405303', 'n_tokens_mistral': 1273, 'n_tokens_neox': 1189, 'n_words': 570}