Rule relapses after upgrade

[delanym]

After upgrading from 1.49.0 to 1.50.0 I get fresh violations of the ReferenceEquality, RefactorSwitch and NotJavadoc rules, but the release notes don't mention anything about them.

I confirmed they are valid, so I'm wondering what changed? Is this a case of errorprone

• not finding the violation because of not comprehensively analyzing the code, or is it
• changes in a rule's algorithm to recognize the violations?

This actually happens quite often, and its probably worth adding to a FAQ.
At the moment its a bit too magical.
I just hope it doesn't go the other way with rules that should be firing no longer doing so!

[delanym]

I got stuck in with a genie and here are the findings

One thing that made the 2.50.0 upgrade harder than it needed to be: the changes that actually broke our -Werror build don't appear on the release page at all. The three culprits were all existing checks that started matching more code rather than new
checks — ReferenceEquality (now flags == on non-final/non-sealed types that don't override equals(), so Thread, ClassLoader, abstract state singletons, most Swing components), the RefactorSwitch:EnableReturnSwitch default flip, and the new
dangling-comment detection in NotJavadoc. None of those are visible without diffing the full v2.49.0...v2.50.0 changelog by hand.

Digging into why, it looks structural rather than an oversight: release.yml builds the notes with generate_release_notes: true, which lists merged PR titles — but since Error Prone is exported from internal commits, most changes never exist as GitHub
PRs and so can't show up there. The frustrating part is that the signal already exists in the repo: you use RELNOTES=/RELNOTES: commit trailers extensively, they're just never harvested into the release page (and the four commits above happen to carry
none). So the fix is probably twofold — generate the notes from the RELNOTES trailers you already write instead of (or alongside) PR titles, and treat "an existing check now produces new findings" / "a default changed" as a first-class category, since
that's the bucket upgraders most need to scan. A light presubmit requiring a RELNOTES line on any change to a matcher or a default flag would keep that category honest. (Minor aside I hit while poking at this: the release commit is tagged but never
merged back to master, so consecutive release tags are siblings — git describe can't walk between them, though a version-sorted v..v range works fine.)