Release lintr 3.1.0 #1476
Comments
|
I think the version for this issue should be changed, since Maybe |
|
renamed the milestone as 3.0.2 for now. we're free to rename it if we decide for a bump to 3.1 |
|
This needs to be bumped again since the latest CRAN is 3.0.2. |
|
Since there are new features and linters in this release I think it should probably be 3.1.0 |
|
Shouldn't we make a new release soon? There is a lot of new functionality already that users can immediately benefit from. |
|
Yes, I think we're about due... |
The submission portal will be closed in this time window, so we need to plan a release either before or after. |
|
Except for #1137, we have PRs for all open issues. If you find time to review in the coming days, I'd favor going for a 3.1.0 release this year. |
|
I'm leaning towards bumping #1137 to the next release, anyone keen to keep it? |
|
I think for #1137 we just need to add documentation to the object_usage_linter stating that the package being linted should be installed before linting. Right? |
|
I'm quite sure |
This is the part that has me leaning towards bumping :) FWIW the documentation should all go on the https://lintr.r-lib.org/reference/executing_linters.html
is a bit short on details |
|
My two cents: We should delay this release until This is one of the default linters, and we will get a number of false positive issues, especially one stemming from a conflict with E.g. I had to turn off this linter in easystats repos because maintainers had started to manually format code to pacify this linter, and these changes were, of course, undone once |
|
I agree #1898 should be resolved before release; for the other ones, #1942 and #1944 are also present in |
|
I have at least an expedient solution to #1945 in #1949, so I added both #1898 and #1945 to the milestone. If we think I think what makes sense is to do our usual release procedure of checking the change in lints on a swath of existing packages; that'll help us get a sense of how crucial these other fixes may be. |
|
Did an initial branch comparison for current (9038957) timings = fread('.dev/lintr_compare_branches_1681201833_benchmark_timings.csv')
timings[,
dcast(.SD, linter + package +filename ~ branch, value.var = "duration")
][,
as.list(summary(main - `v3.0.2`)),
keyby = linter
][!is.na(Min.)][order(Median)]With output: Units are nanoseconds and all of the Q1-Q3 ranges contain 0, so I don't think much has changed w.r.t. performance. (caveat: Thos 19 |
|
Some more quick takeaways (re-ran as of 2b06c52 on 700 packages)
Just dumping this for now, plan to look into more later. Feel free to highlight anything worth inspecting further. (I'd share the results CSV but it's 1.9M rows / 142MiB in memory) lints = fread('.dev/lintr_compare_branches_1681227308.csv')
lints[, source := fifelse(source == "branch", "v3.0.2", "v3.1.0")]
key_cols <- c("source", "package", "filename", "line_number", "column_number", "linter")
lints = unique(lints, by = key_cols)
# Mapping old to new lints:
mapping <- c(
single_quotes_linter = "quotes_linter",
unneeded_concatenation_linter = "unnecessary_concatenation_linter",
consecutive_stopifnot_linter = "consecutive_assertion_linter",
no_tab_linter = "whitespace_linter",
NULL
)
new_linters <- c(
"matrix_apply_linter", "unnecessary_lambda_linter", "redundant_equals_linter",
"lengths_linter", "function_return_linter", "boolean_arithmetic_linter",
"for_loop_index_linter", "is_numeric_linter", "empty_assignment_linter",
"unnecessary_placeholder_linter", "routine_registration_linter", "indentation_linter",
"unnecessary_nested_if_linter", "implicit_assignment_linter",
NULL
)
lints[source == "v3.0.2" & linter %chin% names(mapping), linter := mapping[linter]]
# packages throwing errors on v3.0.2
lints[source == "v3.0.2" & !nzchar(linter), .(package, message)]
lints = lints[nzchar(linter)]
setkeyv(lints, key_cols)
# count of lints per linter by version
dcast(lints, linter ~ source, fun.aggregate = length)[, delta := `v3.1.0` - `v3.0.2`][]
old_only = lints[.("v3.0.2")][!lints[.("v3.0.1")], on = key_cols[-1]]
new_only = lints[.("v3.1.0")][!lints[.("v3.0.2")], on = key_cols[-1]][!linter %chin% new_linters] |
|
Thanks for the analyses. Table 4 seems wrong, looking at the count for |
|
Any update on this? |
narrator: he did not have more time 😄 #1982 fixes the last issue I wanted to check before release. I am happy to move forward after that's merged. |
|
I ran the initial steps in the release procedure, now working on two new ones. First, here's the output of I'll file an issue about investigating the slowdown, e.g. in mlr. I don't remember off-hand whether that timing would organically increase if we just add new default linters, so my first guess is the new |
|
Here are the new warnings vs. 3.0.2: I see a few possible regressions there, filing issues. |
|
@AshesITR @IndrajeetPatil anything else you'd like to see included in this release? #1989 and #1992 are the last PRs for me. Barring that, @jimhester could you take it from here? Let us know how else to help 🙏 Thanks for the hard work everyone! |
Closed
|
The update is on CRAN: https://cran.r-project.org/web/packages/lintr/index.html After making a GitHub release, I think this issue can be closed. |
|
Thanks @jimhester !! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think the fixes we have for our CRAN warnings/errors, as well as the fix for #1405, are enough to warrant a patch release.
So filing this issue (along with the created milestone) for us to earmark some issues/PRs as important enough for inclusion, then we can submit a new release.
Prepare for release:
3.1.0milestonedevtools::check(remote = TRUE, manual = TRUE)devtools::check_win_devel()donerhub::check_for_cran()1 2 3revdepcheck::revdep_check()..dev/revdep_get_repos.Rand.dev/revdep_compare_releases.R.Submit to CRAN:
usethis::use_version('patch')devtools::submit_cran()Wait for CRAN...
cran-comments.mdusethis::use_github_release()usethis::use_dev_version()The text was updated successfully, but these errors were encountered: