Closes #1792 multiple summary vars

[bundfussr]

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue in the Development Section on the right hand side.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[github-actions]

Package	Line Rate	Health
admiral	98%	✔
Summary	98% (4388 / 4457)	✔

[bms63]

Did I see in your function re-work document a recommendation to deprecate this function?

[bundfussr]

Yes, if we add the dataset_add argument to derive_summary_records(), we can deprecate or supersede get_summary_records().

[zdz2101]

Where are the changes from admiraldev::331_allow_grouped affecting the code base/should we merge in that PR first? I saw there isn't too much changed:

[bundfussr]

Where are the changes from admiraldev::331_allow_grouped affecting the code base/should we merge in that PR first? I saw there isn't too much changed:

I cancelled the update in admiraldev because at the end I did not need it.

[zdz2101]

Address merge conflicts, otherwise looks good

[bms63]

this should have admiral (development version) instead of the number. I think usethis::use_version("dev") will update for you

[bundfussr]

Updated, although use_version("dev") did not work well (it increased to 0.12.0.9001 and added an additional heading in NEWS.md and the commit failed). I think we should call use_version("dev") once directly after each release.

[bms63]

I believe every time we merge into main while developing this will be incremented. @zdz2101 @ddsjoberg

[bundfussr]

I would keep it simple and always stay at x.x.x.9000. Even in the "R packages" book it is suggested to increment the development version only in exceptional cases:

Increment the development version, e.g. from 9000 to 9001, if you’ve added an important feature and you (or others) need to be able to detect or require the presence of this feature. For example, this can happen when two packages are developing in tandem. This is generally the only reason that we bother to increment the development version. This makes in-development versions special and, in some sense, degenerate. Since we don’t increment the development component with each Git commit, the same package version number is associated with many different states of the package source, in between releases.

[bms63]

I agree it will make it a lot easier on us if we don't have to change this every time we merge into main. Seems like this will cause a lot of tedious merge conflicts.

[zdz2101]

This does seem to make more sense, I'll remove the running of the line from the PR template, and it can be added as a standard post-release task

[ddsjoberg]

It seems like the admiral family often makes updates that affect downstream dependencies. With that in mind, incrementing the version number will make it easy for these downstream dependencies to ensure the min dev version is installed. @cicdguy created a workflow to increment the dev version number with each PR, and I think it's a good addition to include in admiral

[bms63]

Suggested change

	#' (`dataset`) by the specified by variables.
	#' (`dataset`) by the specified **by variables**.

I got confused

[bundfussr]

The by variables are used twice. I have emphasized both.

[bundfussr]

I also added more details to "Details".

[bms63]

@bundfussr once you catch up from your vacay - can you resolve merge conflicts please.