Bump version to 18.0 and fix master references18.0

Fix more URLs to point to main.

Signed-off-by: Tim Smith <tsmith@chef.io>

5 files changed, 18 insertions, 16 deletions

diff --git a/docs/dev/how_to/adding_new_platforms_to_infra.md b/docs/dev/how_to/adding_new_platforms_to_infra.md
index 99a2544710..a2a8e4a01b 100644
--- a/docs/dev/how_to/adding_new_platforms_to_infra.md
+++ b/docs/dev/how_to/adding_new_platforms_to_infra.md
@@ -16,13 +16,13 @@ For major new Linux or Windows distribution releases, you'll want to add these t
 
 Note: Windows builds can't be built on DockerHub and have to be pushed manually from your workstation instead.
 
-Once you've added the distro to RubyDistros and the image is pushed to DockerHub, you can add that new distro to the `chef/chef` [verify.pipeline.yml](https://github.com/chef/chef/blob/master/.expeditor/verify.pipeline.yml).
+Once you've added the distro to RubyDistros and the image is pushed to DockerHub, you can add that new distro to the `chef/chef` [verify.pipeline.yml](https://github.com/chef/chef/blob/main/.expeditor/verify.pipeline.yml).
 
 #### Kitchen Dokken Images
 
 We utilize the kitchen-dokken Test Kitchen plugin to test the contents of `chef/chef` against various Linux distributions. This works best when run against containers that look more like VMs and less like slim containers. The [dokken-images](https://github.com/test-kitchen/dokken-images) repository defines many Docker images for common Linux distributions. These are all based on the official distro Docker images but contain additional packages to make them behave more like full systems.
 
-Similar to the RubyDistros setup, these are defined in GitHub and built-in DockerHub. You'll need to be a member of the [dokken DockerHub organization](https://hub.docker.com/orgs/dokken). If you don't have access to that please ask #releng-support to add you. Once you've added a distro to the GitHub repo you can add a new repository to that DockerHub Organization. Make sure to copy the automated builds settings and specify the correct path to the Dockerfile. Once that is complete and the image is pushed to DockerHub you can add the new test to `chef/chef`. You'll need to edit the [kitchen-test/kitchen.yml](https://github.com/chef/chef/blob/master/kitchen-tests/kitchen.yml) file and then add that new platform to the [verify.pipeline.yml](https://github.com/chef/chef/blob/master/.expeditor/verify.pipeline.yml) config.
+Similar to the RubyDistros setup, these are defined in GitHub and built-in DockerHub. You'll need to be a member of the [dokken DockerHub organization](https://hub.docker.com/orgs/dokken). If you don't have access to that please ask #releng-support to add you. Once you've added a distro to the GitHub repo you can add a new repository to that DockerHub Organization. Make sure to copy the automated builds settings and specify the correct path to the Dockerfile. Once that is complete and the image is pushed to DockerHub you can add the new test to `chef/chef`. You'll need to edit the [kitchen-test/kitchen.yml](https://github.com/chef/chef/blob/main/kitchen-tests/kitchen.yml) file and then add that new platform to the [verify.pipeline.yml](https://github.com/chef/chef/blob/main/.expeditor/verify.pipeline.yml) config.
 
 #### Azure Pipelines tests
 
@@ -40,17 +40,17 @@ With builds in place, we also want to make sure we support this new platform wit
 
 #### chef-utils
 
-chef-utils provides a large number of helpers for making cookbook authoring simpler. One of the most useful sets of helpers is helpers for platforms and platform families, which will need to be updated if we added new distros. Make sure new platform are supported in `platform.rb` / `platform_family.rb` files in [chef-utils/lib/chef-utils/dsl](https://github.com/chef/chef/tree/master/chef-utils/lib/chef-utils/dsl). In order to test these changes you'll most likely need to update the Fauxhai data. See the section below for instructions on updating that data.
+chef-utils provides a large number of helpers for making cookbook authoring simpler. One of the most useful sets of helpers is helpers for platforms and platform families, which will need to be updated if we added new distros. Make sure new platform are supported in `platform.rb` / `platform_family.rb` files in [chef-utils/lib/chef-utils/dsl](https://github.com/chef/chef/tree/main/chef-utils/lib/chef-utils/dsl). In order to test these changes you'll most likely need to update the Fauxhai data. See the section below for instructions on updating that data.
 
 #### Ohai
 
-Ohai powers all system configuration detection for Chef Infra Client. New distributions have pretty far-reaching impacts on Ohai and should be evaluated carefully. The most basic task when adding a new distro is to make sure that the platform is properly mapped to the appropriate platform_family value. On Linux systems this is performed in the [Linux Platform Plugin](https://github.com/chef/ohai/blob/master/lib/ohai/plugins/linux/platform.rb).
+Ohai powers all system configuration detection for Chef Infra Client. New distributions have pretty far-reaching impacts on Ohai and should be evaluated carefully. The most basic task when adding a new distro is to make sure that the platform is properly mapped to the appropriate platform_family value. On Linux systems this is performed in the [Linux Platform Plugin](https://github.com/chef/ohai/blob/main/lib/ohai/plugins/linux/platform.rb).
 
 ## Additional Ecosystem Updates
 
 ### Bento Boxes
 
-Bento boxes are used by the kitchen-vagrant driver by customers for cookbook testing. When we add a new platform we need to make sure that customers can use it in their testing processes. The [bento repository](https://github.com/chef/bento/) contains packer templates for each platform / platform version, a [builds.yml](https://github.com/chef/bento/blob/master/builds.yml) file which defines the systems to build, and a ruby application which helps with building systems. Bento boxes are generally build for VirtualBox, VMware Fusion, Parallels Desktop, and Hyper-V so you will need both a macOS and Windows system to build all the systems. Once this is complete you can use the `bento upload` command to push these to Vagrant Cloud. You'll need to be added to the Bento Vagrant Cloud org, which #releng-support can assist you with.
+Bento boxes are used by the kitchen-vagrant driver by customers for cookbook testing. When we add a new platform we need to make sure that customers can use it in their testing processes. The [bento repository](https://github.com/chef/bento/) contains packer templates for each platform / platform version, a [builds.yml](https://github.com/chef/bento/blob/main/builds.yml) file which defines the systems to build, and a ruby application which helps with building systems. Bento boxes are generally build for VirtualBox, VMware Fusion, Parallels Desktop, and Hyper-V so you will need both a macOS and Windows system to build all the systems. Once this is complete you can use the `bento upload` command to push these to Vagrant Cloud. You'll need to be added to the Bento Vagrant Cloud org, which #releng-support can assist you with.
 
 ### Fauxhai Dumps
 
diff --git a/docs/dev/how_to/branching_and_backporting.md b/docs/dev/how_to/branching_and_backporting.md
index 8929c926e9..ab601cadba 100644
--- a/docs/dev/how_to/branching_and_backporting.md
+++ b/docs/dev/how_to/branching_and_backporting.md
@@ -2,16 +2,16 @@
 
 ## Branch Structure
 
-We develop and ship the current release of Chef off the master branch of this repository. Our goal is that `master` should always be in a shippable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-14 or chef-13). We do not perform direct development on these stable branches, except to resolve build failures. Instead, we backport fixes from our master branch to these stable branches. Stable branches receive critical bugfixes and security releases, and stable Chef releases are made as necessary for security purposes.
+We develop and ship the current release of Chef off the `main` branch of this repository. Our goal is that `main` should always be in a shippable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-16 or chef-15). We do not perform direct development on these stable branches, except to resolve build failures. Instead, we backport fixes from our main branch to these stable branches. Stable branches receive critical bugfixes and security releases, and stable Chef releases are made as necessary for security purposes.
 
 ## Backporting Fixes to Stable Releases
 
-If there is a critical fix that you believe should be backported from master to a stable branch, please follow these steps to backport your change:
+If there is a critical fix that you believe should be backported from main to a stable branch, please follow these steps to backport your change:
 
 1. Ask in the #chef-dev channel on [Chef Community Slack](https://community-slack.chef.io/) if this is an appropriate change to backport.
 3. Inspect the Git history and find the `SHA`(s) associated with the fix.
 4. Backport the fix to a branch via cherry-pick:
-    1. Check out the stable release branch: `git checkout chef-14`
+    1. Check out the stable release branch: `git checkout chef-16`
     2. Create a branch for your backport: `git checkout -b my_great_bug_backport`
     3. Cherry Pick the SHA with the fix: `git cherry-pick SHA`
     4. Address any conflicts (if necessary)
diff --git a/docs/dev/how_to/bumping_minor_or_major_versions.md b/docs/dev/how_to/bumping_minor_or_major_versions.md
index 79cfa9075e..b8164ea1bf 100644
--- a/docs/dev/how_to/bumping_minor_or_major_versions.md
+++ b/docs/dev/how_to/bumping_minor_or_major_versions.md
@@ -4,7 +4,7 @@
 
 After performing the monthly minor release of Chef, we should wait several days, and then bump the version for the next month's release. Why wait? We don't want to bump the version until we are sure we do not need to perform an emergency release for a regression. Once we're fairly confident we won't be performing a regression release, we want all new builds for the current channel to have the next month's version. This makes it very clear what version of Chef users are testing within the current channel.
 
-Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on master will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
+Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on main will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
 
 See [Bumping The Major Version](bumping_the_major_version.md) for the major version bump process.
 
diff --git a/docs/dev/how_to/bumping_the_major_version.md b/docs/dev/how_to/bumping_the_major_version.md
index 32d0498153..12d7435dbb 100644
--- a/docs/dev/how_to/bumping_the_major_version.md
+++ b/docs/dev/how_to/bumping_the_major_version.md
@@ -29,25 +29,27 @@ Starting from the main branch create a PR which:
 
 ### Prep main branch for forking
 
-- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constraint for main to match the new planned major version and add a constraint for the new stable version / branch. Make sure to commit this before moving on.
+- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constraint for main to match the new planned major version and add a constraint for the new stable version / branch.
 
 ### Fork Chef main to a stable branch
 
 Before bumping the major version of Chef Infra we want to fork off the current main to a new stable branch, which will be used to build hotfix releases. We support the N-1 version of Chef Infra Client for a year after the release of a new major version. For example Chef Infra Client 17 was released in April 2021, at which point Chef Infra Client 16 became the N-1 release. Chef Infra Client 16 will then be maintained with critical bug and security fixes until April 2022.
 
-On your local machine fork the current main branch to a new stable branch. For example: `git checkout -b chef-16` and `git push --set-upstream origin chef-16`, which can then be pushed up to GitHub.
+On your local machine fork the current main branch to a new stable branch. For example: `git checkout -b chef-17` and `git push --set-upstream origin chef-17`, which can then be pushed up to GitHub.
 
 ### Create a branch to fixup your new stable branch for release
 
-Once you've forked to a new stable branch such as `chef-15` you'll want to create a new branch so you can build a PR, which will get this branch ready for release:
+Once you've forked to a new stable branch such as `chef-17` you'll want to create a new branch so you can build a PR, which will get this branch ready for release:
 
-- In ./expeditor/config.yml remove all the update_dep.sh subscriptions which don't work against stable branches.
+- In ./expeditor/config.yml remove the update_dep.sh subscriptions which don't work against stable branches such as chefstyle and ohai.
 - In readme.md update the buildkite badge to point to the new stable branch image and link instead of pointing to main.
 - In kitchen-tests/Gemfile update the Ohai branch to point to the new Ohai stable
 - In kitchen-tests/kitchen.yml update chef_version to be your new stable version and not current. Ex: 15
 - In tasks/bin/run_external_test update the ohai branch to point to your new stable ohai branch
 - In Gemfile set ohai to pull from the ohai stable branch
-- Run `rake dependencies:update`
+- In Gemfile set cheffish to match the stable release of chef
+- Update .github/dependabot.yml with the new branch
+- Run `rake dependencies:update` to generate a new gemfile.lock
 
 Example PR for Chef 15: https://github.com/chef/chef/pull/9236
 
@@ -58,7 +60,7 @@ Note: Make sure you're making this PR against the new stable branch and not main
 Create a PR that performs the following:
 
 - Update the version in the VERSION file
-- Update chef.gemspec to point to the new ohai major release
+- Update `chef.gemspec` and `knife.gemspec` to point to the new ohai major release
 - run `rake dependencies:update`
 
 ## Update Ohai stable for the Chef stable branch
diff --git a/docs/dev/how_to/releasing_chef_infra.md b/docs/dev/how_to/releasing_chef_infra.md
index b0db85432e..6e6f926395 100644
--- a/docs/dev/how_to/releasing_chef_infra.md
+++ b/docs/dev/how_to/releasing_chef_infra.md
@@ -37,7 +37,7 @@ If there are any new or updated resources, the docs site will need to be updated
 
 Chef employees can promote a build to stable from Slack. This is done with expeditor using a chatops command in the following format:
 
-`/expeditor promote chef/chef:master 17.1.9`
+`/expeditor promote chef/chef:main 17.1.9`
 
 or for a previous release branch: