Merge branch 'main' into dev_nextrelease

.github/CONTRIBUTING.md

@@ -109,7 +109,7 @@ A tibble is a dataframe that makes working in the tidyverse a little [easier](ht
 We try to follow the [GitHub flow](https://guides.github.com/introduction/flow/) for development.
 
 1. Fork [this repo][repo] and clone it to your computer. To learn more about this process, see [this guide](https://guides.github.com/activities/forking/).
-2. If you have forked and cloned the project before and it has been a while since you worked on it, [pull changes from the original repo](https://help.github.com/articles/merging-an-upstream-repository-into-your-fork/) to your clone by using `git pull upstream master`.
+2. If you have forked and cloned the project before and it has been a while since you worked on it, [pull changes from the original repo](https://help.github.com/articles/merging-an-upstream-repository-into-your-fork/) to your clone by using `git pull upstream main`.
 3. Open the RStudio project file (`.Rproj`).
 5. Make your changes:
     * Write your code.
@@ -131,23 +131,23 @@ You will want to look at the file `src/manage_package.R` to get some useful pack
 **Releases, version numbering and the relation to git branches**
 
 - We follow the semantic version numbering as described [here](https://r-pkgs.org/description.html#version).
-- The commit referred to by `master` (branch tip) must always have a `<major>.<minor>.<patch>` version number in the `DESCRIPTION` file.
+- The commit referred to by `main` (branch tip) must always have a `<major>.<minor>.<patch>` version number in the `DESCRIPTION` file.
 It is the latest released package version.
-  - Subsequent commits on `master` which do not change the package code itself, but only website setup and repo documentation, must inherit the _same_ release version number.
+  - Subsequent commits on `main` which do not change the package code itself, but only website setup and repo documentation, must inherit the _same_ release version number.
   - **Commits which do change the package _must_ carry a development version number**; typically `<major>.<minor>.<patch>.9000`.
-It follows that they never appear at the tip of the `master` branch.
+It follows that they never appear at the tip of the `main` branch.
 Non-package commits _may_ follow this route as well: it is safe for all new commits.
 
   These conventions ensure that:
-  - a simple package installation with `remotes::install_github()`, which defaults to downloading from the `master` branch, will result in an installation of the latest release;
+  - a simple package installation with `remotes::install_github()`, which defaults to downloading from the `main` branch, will result in an installation of the latest release;
   - the `pkgdown` [website] shows the version number of the latest release.
 
-- Other branches than `master` can have various names.
+- Other branches than `main` can have various names.
 However, there is always at least one **development branch** whose name begins with `dev`.
 For example: `dev_nextrelease`, `dev_0.4.0`, ...
 It is the collector of new features and bugfixes that will lead to a later release, and its first commit should be to add a dev-suffix (`.9000`) to the current version number (don't increment `<major>.<minor>.<patch>`).
   - Especially when cooperating, it is counteradvised to push directly to this branch; better do so through pull requests from feature branches.
-- Eventually, the development branch's last commit before merging to `master` will be to increment at least one of `<major>`, `<minor>` or `<patch>` and to drop the dev-suffix from the version number (i.e. in the `DESCRIPTION` file).
+- Eventually, the development branch's last commit before merging to `main` will be to increment at least one of `<major>`, `<minor>` or `<patch>` and to drop the dev-suffix from the version number (i.e. in the `DESCRIPTION` file).
 Such final commits should happen directly on the development branch.
 No later than that commmit (but it can safely be done earlier), also the `.zenodo.json` metadata file must be updated to the new release version number.
 
@@ -170,7 +170,7 @@ This is needed to ensure a smooth merge of your branch to the base branch later
 1. Propose to merge your commits into the base branch: after pushing your branch to GitHub (which you can do repeatedly), this starts with making a **pull request** (PR; actually this is a merge request) and assign at least one reviewer before a merge can be decided.
 At that moment, open online discussion in the repo is possible on your changes (for other open discussion that you want to start, make an _issue_).
 As long as no merge is performed, more commits can be added to this PR with `git push`, e.g. to implement requested changes by others.
-    - make sure to correctly **set the base branch** in the pull request (because the default is `master`).
+    - make sure to correctly **set the base branch** in the pull request (because the default is `main`).
 1. After your PR is merged, pull the base branch and clean up your local repo in order to keep up with the remote.
 
 **Git resources**

README.md

@@ -25,7 +25,7 @@ Currently the R package won't work outside INBO.
 
 ### Option 1: from r-universe repository (quickest)
 
-To install the current package version from the `master` branch (latest stable release), run:
+To install the current package version from the `main` branch (latest stable release), run:
 
 ```r
 install.packages("watina", repos = c(inbo = "https://inbo.r-universe.dev", 
@@ -56,7 +56,7 @@ remotes::install_github("inbo/watina",
                         upgrade = TRUE)
 ```
 
-Note that this will install the package from the `master` branch.
+Note that this will install the package from the `main` branch.
 If you need a version from another branch, add the `ref` argument in the above function to provide the branch name.
 
 ## You are welcome to contribute!