diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index aa9a1e9..1a4549f 100644 --- a/.github/CONTRIBUTING.md +++ b/.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 `..` version number in the `DESCRIPTION` file. +- The commit referred to by `main` (branch tip) must always have a `..` 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 `...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 `..`). - 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 ``, `` or `` 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 ``, `` or `` 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** diff --git a/README.md b/README.md index 3ba46d2..926330d 100644 --- a/README.md +++ b/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!