docs: use American English spelling for word behavior (#7969)

* docs: use American English spelling for word behavior

* Revert "docs: use American English spelling for word behavior"

This reverts commit 5952fe7.

* behaviour -> behavior for md files in docs/**

* change behaviour -> behavior for lib/versioning/poetry

docs/development/design-decisions.md

@@ -31,10 +31,10 @@ From most specific to least specific:
 
 ## Automatic discovery of package file locations
 
-The default behaviour is to auto-discover all package file (e.g. `package.json`) locations in a repository and process them all.
+The default behavior is to auto-discover all package file (e.g. `package.json`) locations in a repository and process them all.
 Doing so means that "monorepos" are supported by default.
 
-This behaviour can be overridden by the configuration option `includePaths`, where you list the file paths manually.
+This behavior can be overridden by the configuration option `includePaths`, where you list the file paths manually.
 You could limit Renovate to only update the `package.json` in the root of the repository and ignore `package.json` files in other directories.
 
 ## Separate Branches per dependency
@@ -57,7 +57,7 @@ Our reasons for separating minor and major PRs:
 - It's also often the case that previous major versions continue receiving Minor or Patch updates
 - Projects should get Minor and Patch updates for their current Major release even if a new Major release exists
 
-This behaviour can be overridden via the config option `separateMajorMinor`.
+This behavior can be overridden via the config option `separateMajorMinor`.
 
 ## Branch naming
 
@@ -77,7 +77,7 @@ This allows users to close unwelcome upgrade PRs and not worry about them being
 
 ## Rebasing Unmergeable Pull Requests
 
-With the default behaviour of one branch per dependency, it's often the case that a PR gets merge conflicts after an adjacent dependency update is merged.
+With the default behavior of one branch per dependency, it's often the case that a PR gets merge conflicts after an adjacent dependency update is merged.
 Although platforms often have a web interface for simple merge conflicts, this is still annoying to resolve manually.
 
 `renovate` will rebase any unmergeable branches and add the latest necessary commit on top of the most recent `master` commit.

docs/usage/config-presets.md

@@ -67,7 +67,7 @@ A typical onboarding `renovate.json` looks like this:
 }
 ```
 
-Say you want to modify the default behaviour, for example scheduling Renovate to process upgrades during non-office hours only.
+Say you want to modify the default behavior, for example scheduling Renovate to process upgrades during non-office hours only.
 To do this you can modify the default `renovate.json` file like this:
 
 ```json

docs/usage/configuration-options.md

@@ -296,7 +296,7 @@ The "topic" is usually refers to the dependency being updated, e.g. `"dependency
 
 ## configWarningReuseIssue
 
-Renovate's default behaviour is to reuse/reopen a single Config Warning issue in each repository so as to keep the "noise" down.
+Renovate's default behavior is to reuse/reopen a single Config Warning issue in each repository so as to keep the "noise" down.
 However for some people this has the downside that the config warning won't be sorted near the top if you view issues by creation date.
 Configure this option to `false` if you prefer Renovate to open a new issue whenever there is a config warning.
 
@@ -1566,7 +1566,7 @@ Currently the only Python package manager is `pip` - specifically for `requireme
 
 ## rangeStrategy
 
-Behaviour:
+Behavior:
 
 - `auto` = Renovate decides (this will be done on a manager-by-manager basis)
 - `pin` = convert ranges to exact versions, e.g. `^1.0.0` -> `1.1.0`
@@ -1613,7 +1613,7 @@ Note: this field replaces the previous fields of `rebaseConflictedPrs` and `reba
 
 By default, Renovate will detect if it has proposed an update to a project before and not propose the same one again.
 For example the Webpack 3.x case described above.
-This field lets you customise this behaviour down to a per-package level.
+This field lets you customise this behavior down to a per-package level.
 For example we override it to `true` in the following cases where branch names and PR titles need to be reused:
 
 - Package groups
@@ -1846,7 +1846,7 @@ The field supports multiple URLs however it is datasource-dependent on whether o
 
 ## requiredStatusChecks
 
-Currently Renovate's default behaviour is to only automerge if every status check has succeeded.
+Currently Renovate's default behavior is to only automerge if every status check has succeeded.
 
 Setting this option to `null` means that Renovate will ignore all status checks.
 You need to set this if you don't have any status checks but still want Renovate to automerge PRs.
@@ -1876,7 +1876,7 @@ Take a random sample of given size from reviewers.
 
 ## rollbackPrs
 
-Configure this to `false` either globally, per-language, or per-package if you want to disable Renovate's behaviour of generating rollback PRs when it can't find the current version on the registry anymore.
+Configure this to `false` either globally, per-language, or per-package if you want to disable Renovate's behavior of generating rollback PRs when it can't find the current version on the registry anymore.
 
 ## ruby
 
@@ -1953,7 +1953,7 @@ However, please note that Renovate will autodetect if your repository is already
 
 ## separateMajorMinor
 
-Renovate's default behaviour is to create a separate branch/PR if both minor and major version updates exist (note that your choice of `rangeStrategy` value can influence which updates exist in the first place however).
+Renovate's default behavior is to create a separate branch/PR if both minor and major version updates exist (note that your choice of `rangeStrategy` value can influence which updates exist in the first place however).
 For example, if you were using Webpack 2.0.0 and versions 2.1.0 and 3.0.0 were both available, then Renovate would create two PRs so that you have the choice whether to apply the minor update to 2.x or the major update of 3.x.
 If you were to apply the minor update then Renovate would keep updating the 3.x branch for you as well, e.g. if Webpack 3.0.1 or 3.1.0 were released.
 If instead you applied the 3.0.0 update then Renovate would clean up the unneeded 2.x branch for you on the next run.
@@ -1975,7 +1975,7 @@ If you wish to distinguish between patch and minor upgrades, for example if you
 ## separateMultipleMajor
 
 Configure this to `true` if you wish to receive one PR for every separate major version upgrade of a dependency.
-e.g. if you are on webpack@v1 currently then default behaviour is a PR for upgrading to webpack@v3 and not for webpack@v2.
+e.g. if you are on webpack@v1 currently then default behavior is a PR for upgrading to webpack@v3 and not for webpack@v2.
 If this setting is true then you would get one PR for webpack@v2 and one for webpack@v3.
 
 ## stabilityDays

docs/usage/docker.md

@@ -31,7 +31,7 @@ Although suffixes in semver indicate pre-releases (e.g. `v1.2.0-alpha.2`), in Do
 Renovate defaults to assuming suffixes indicate compatibility so will never _change_ it.
 e.g. `12.1.0-alpine` might get updated to `12.1.1-alpine` but never `12.1.1` or `12.1.1-stretch`.
 
-If this behaviour does not suit a particular package you have, Renovate allows you to customize the `versioning` in use.
+If this behavior does not suit a particular package you have, Renovate allows you to customize the `versioning` in use.
 For example, if you have a Docker image `foo/bar` that sticks to semver versioning and you need Renovate to understand that suffixes indicate pre-releases versions and not compatibility, then you could configure this package rule:
 
 ```json

docs/usage/faq.md

@@ -5,7 +5,7 @@ description: Frequently Asked Questions for Renovate Configuration
 
 # Frequently Asked Questions (FAQ)
 
-## What Is The Default Behaviour?
+## What Is The Default Behavior?
 
 Renovate will:
 
@@ -183,7 +183,7 @@ Nest it inside config objects `patch` or `minor` if you want it to apply to cert
 
 ### Separate patch releases from minor releases
 
-Renovate's default behaviour is to separate major and minor releases, while patch releases are also consider "minor".
+Renovate's default behavior is to separate major and minor releases, while patch releases are also consider "minor".
 For example if you were running `q@0.8.7` you would receive one branch for the minor update to `q@0.9.7` and a second for the major update to `q@1.4.1`.
 
 If you set the configuration option `separateMinorPatch` to `true`, or you configure `automerge` to have value `"patch"`, then Renovate will then separate patch releases as well.

lib/versioning/poetry/readme.md

@@ -1,3 +1,3 @@
 Poetry versioning is a little like a mix of PEP440 and SemVer.
 
-Currently Renovate's implementation is based off npm versioning, but it is being migrated to be based off PEP440 to be more compatible with Poetry's behaviour.
+Currently Renovate's implementation is based off npm versioning, but it is being migrated to be based off PEP440 to be more compatible with Poetry's behavior.