usethis::create_package("mypackage").DESCRIPTION file should define:Package:
Title:
Description:
Version:
Authors@R:
role = "cre" for the maintainer,
role = "aut" for substantial authorship, and
role = "ctb" for smaller contributions.
License:
Depends:
R (>= 4.0.0)
Imports:
Suggests:
RoxygenNote: 8.0.0
Encoding: UTF-8
Language: en-GB`
Use roxygen2 for documentation so that NAMESPACE and man/ Files are generated automatically.
Functions should be stored in the R folders and tests in the tests folder.
Create a README template with: usethis::use_readme_rmd() . The README should include:
Every package must/optionaly have an explicit licence. The licence field must also be correct in DESCRIPTION.
All packages should pass: devtools::check(). Packages should pass checks on the main platforms used by the community, especially Linux, macOS, and Windows.
Add package-level documentation with: usethis::use_package_doc() . This creates a package documentation file, usually: R/mypackage-package.R. Use it to describe the package’s overall purpose and main workflows.
Include a citation file when the package supports published research, has a citable method, or should be referenced in academic work. usethis::use_citation(). This creates: inst/CITATION .
Include at least one vignette when the package needs a worked example or workflow explanation. Use: usethis::use_vignette("getting-started") .
If including Logo, store it in: man/figures/logo.png.
DataSHIELD packages should follow camel case naming conventions. Client packages should use the suffix Client.
Function names in server and client-side packages follow camelCase naming , DS is used as a suffix in server-side and ds. as prefix in client-side packages.
Examples:
| Server package | Client package | |
|---|---|---|
dsBase |
dsBaseClient |
|
asListDS |
ds.asList |
Function names |
All DataSHIELD packages should be tracked using Git for version control.
Recommended repository practices:
- Use Git from the start of package development
- Host repositories on GitHub (preferred)
- Use `main` as the default branch name, stable development branch
- Commit changes frequently with meaningful commit messages
- Use pull requests for reviewing changes before merging
DataSHIELD packages should follow the standard tidyverse-style versioning convention: <major>.<minor>.<patch> . The version number should be updated in the DESCRIPTION file.
The first stable and shareable package version should normally be: 0.1.0 .
Packages should maintain a NEWS.md file documenting changes between versions.
Recommended contents:
- New features
- Bug fixes
- Breaking changes
- Deprecated functions
- Documentation improvements
At a minimum, contributors associated with a feature or bug fix should be acknowledged near the corresponding entry where appropriate.
Git tags for releases: Each package release should be associated with a Git tag.
Release workflow recommendations: A typical release workflow should include:
1. Update package version in DESCRIPTION
2. Update NEWS.md
3. Run package checks
* devtools::check()
* R CMD check
4. Run tests
* testthat::test_dir()
* CI pipeline
5. Run linting/style checks (optional but recommended)
* lintr
* styler
5. Commit release changes
6. Push commits and tags to remote repository (main)
7. Submit to CRAN
8. After CRAN accepts, merge the main to production branch
9. Create git tag.