Release lintr 3.2.0

[MichaelChirico]

Glanced at the NEWS and there's plenty there already for us to ship off to CRAN.

Prepare for release:

• 3.2.0 milestone
• Re-read and refine the entire NEWS for the release
• Ensure backport_linter() covers all released R versions
• Check URLs: urlchecker::url_check() or tools:::check_url_db(tools:::url_db_from_package_sources("."))
• Run the R-CMD-check GHA on all released R versions on Ubuntu, Mac, and Windows. See Check which versions of R touch the while() loop in get_source_expressions() #2501 for reference.
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel() or devtools::check_win_devel(email = "your@email")
• rhub::check_for_cran() or rhub::check_for_cran(email = "your@email")
• Run revdepcheck::revdep_check(). Check in revdep results #2189
• Run .dev/revdep_get_repos.R and .dev/revdep_compare_releases.R.

Submit to CRAN:

• usethis::use_version('patch')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Update cran-comments.md
• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Toot/Tweet

[MichaelChirico]

@AshesITR with the CRAN failure (#2527), let's decide how to proceed. Options I see:

1. Quick patch release -- branch from 3.1.1, fix only CRAN failures on R-devel #2527, release to CRAN as 3.1.2 (also mirror the change on main)
2. Finish up the last two milestone (https://github.com/r-lib/lintr/milestone/7) issues: Should xml_find_function_calls()` land on on the parent expr instead? #2431 (related PR: New parameter 'land_on' to xml_find_function_calls() #2496), Add exception in unnecessary_nesting_linter() for paired stop()/warning() branches #2325.
3. Delay Should xml_find_function_calls()` land on on the parent expr instead? #2431 by reverting add xml_find_function_calls() helper to source expressions #2357 for this release
4. Delay Should xml_find_function_calls()` land on on the parent expr instead? #2431 by making note in the NEWS that add xml_find_function_calls() helper to source expressions #2357 is experimental/subject to change in the next release

#2325 is also not strictly required for this release, but we have the implementation ready & just need to decide on argument naming/defaults IIRC.

Let me know your thoughts based on your availability in the next two weeks or so.

[AshesITR]

I won't be able to contribute anything meaningful in the upcoming weeks unfortunately.

My hunch is option 1 (maybe including the maintainer change) is the least risky, but I trust your judgement.

[MichaelChirico]

SGTM! FYI (cc also @IndrajeetPatil), I don't plan any major change from taking over maintainership, I just think of it as passing responsibility for the actual CRAN submission process from Jim to me. GH review/etc process has been working pretty well in general.

[IndrajeetPatil]

@MichaelChirico, @AshesITR Should we make a new release soon?

I am taking the amount of time it takes for me to scroll NEWS to get to the released version as a good indicator that enough has improved to be made available to the users. WDYT?

[MichaelChirico]

Yes, we're absolutely on the precipice of release. But I'm stuck on #2431, there's a bit of a design decision there that would be harder to change after release & haven't found the time to come to a proper conclusion there yet. Opinions+insights welcome.

Or, we can just mark that as "experimental/likely to change" and go ahead and release.