- Has the version number been bumped for releasing? This can be done by merging in a PR that has the "Expeditor: Bump Version Minor" label applied.
- Are there any outstanding community PRs that should be merged? Ideally we don't make a community member wait multiple months for a code contribution to ship. Merge anything that's been reviewed.
- Are new resource "introduced" fields using the correct version? From time to time, we incorrectly merge a PR that has the wrong "introduced" version in a new resource or new resource property. If we added new resources or properties, make sure these fields match the version we are about to ship.
- Have any changes in Ohai been shipped to rubygems?
- Do we have a build in the
current
channel? If not, you might wanna fix that.
The importance of our release notes cannot be understated. As developers, we understand changes between releases and we are accustomed to reading git history. Users are not, and if we don't call out new functionality, they will not find it on their own. We need to take the time and effort to write quality release notes that give a compelling reason to upgrade and also properly warn of any potential breaking changes. Make sure to involve the docs team so we can make sure our English is legible.
New features
: Document important / major new features. This is a great opportunity to show off our work and sell users on new workflows.Compliance Phase Improvements
: We should always call out the updated Chef InSpec release and include a description of new functionality. If we've improved how compliance phase operates overall also call that out.New Resources
: If we ship new resources, we want to make sure to brag about those resources. Use this section to give the elevator pitch for the new resource, including an example of how it might be used if available.Updated Resources
: It's important to let users know about new functionality in resources they may already be using. Cover any important bug fixes or new properties/actions here.Security Updates
: Call out any updated components we are shipping and include links to the CVEs if available.
If there are any new or updated resources, the docs site will need to be updated. This is a partially
automated process. If you are making a single resource update or changing wording, it may just be easier to do it by hand.
- Run
rake docs_site:resources
to generate content to adocs_site
directory - Compare the relevant generated files to the content in the
content/resources
directory within the chef-web-docs repo. The generated files are missing some content, such as action descriptions, and don't have perfect formatting, so this is a bit of an art form.
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:main 17.1.9
or for a previous release branch:
/expeditor promote chef/chef:chef-16 16.13.9
Also, make sure to announce the build on any social media platforms that you occupy if you feel comfortable doing so. It's great to make an announcement in #sous-chefs
and #general
in Community Slack, as well as on Twitter, where we tend to get a good response.
Many of our users consume Chef via Homebrew using our casks. Expeditor will create a pull request to update the Chef Homebrew cask, which will need to be merged here: https://github.com/chef/homebrew-chef
Many Windows users consume our packages via Chocolatey. Make sure to update the various version strings and sha checksums here: https://github.com/chef/chocolatey-packages
Once this is updated, you'll need to build / push the artifact to the Chocolatey site from a Windows host:
choco pack .\chef-client\chef-client.nuspec
choco push .\chef-client.15.1.9.nupkg --key API_KEY_HERE
Note: In order to push the artifact, you will need to be added as a maintainer on Chocolatey.org.
You're done. You have a month to relax.