Release v4.7.0

[adammathys]

New minor release of Solidus

We are committed to release every quarter in order to have a constant and predictable cadence for our deliverables.

For more information, check out our Release Policy page.

Here are the steps to follow to release a new minor version.

They are written in the order required to make the process work. However, some material necessary for the release should be prepared before starting with those steps, like the text of the upgrade guide or the messages to send to the community.

💎 GitHub and RubyGems

Release preparation

• Be sure there are no pending PRs that you want to include in the next minor.
• Run the Prepare Release Workflow, leaving main as the branch and the checkbox to prepare the next major unchecked (unless necessary), a new auto-generated PR will appear.
• Make sure everything looks good in the new PR.
• Merge it.

More details about the release workflows are described on our
Release pipeline automation wiki page,
which we encourage to review if the assignee is not familiar with the topic.

Release the Solidus gems on Rubygems

To officially release the Solidus gems, you need to have permissions on RubyGems, with 2FA enabled.

Open Solidus on your local machine and run:

git checkout main
git pull
bin/rake release

You will be prompted to enter your 2FA code multiple times, one for each solidus' subgems.

• Release on RubyGems

After-release Chores

Now that Solidus has been released, we need to cleanup the main branch to get ready for
the next release. As you may have noticed, when the "Release Preparation" PR has been merged, a new PR has been automatically created. That PR already contains the code to get our repository
clean and ready.

There's also another PR auto-generated, which takes care of getting the newly created branch ready to accept new contributions and ready for the next patch release.

• Merge Post-release chores after having released Solidus vX.Y
• Merge Post-creation chores after new vX.Y patch branch

🌱 Ecosystem

• [Guides] Publish upgrade instruction for the new version → Add v4.2 edgeguides#124.
• [Guides] Create a new version with docusaurus of the guides, pointing the main one to the last version released (npm run docusaurus docs:version X.Y) → Add v4.2 edgeguides#124.
• [Starter Frontend] Create a new matching branch (e.g. v3.3)
• [Starter Frontend] In the new branch (e.g. v3.3), change the default solidus target branch in the CircleCI Config to point to the newly created branch.
• [Starter Frontend] Change Latest Version Nightly build Scheduled Pipeline's trigger to point to the newly created branch (e.g. v3.3).
• [CircleCI Extensions Orb] Change current and older commands to reflect the new versions status. When merged, craft a new release to publish the orb on the CircleCI registry. → Support v4.2 circleci-orbs-extensions#88
• [REST API docs] In the Branches section, track the new version's branch and set it as default.

📣 Announcements

• [solidus.io] Create a new blog post that links to the upgrade instructions on our guides.
• [Slack] Notify the community in the #general channel.
• [RubyFlow] Post an update to get visibility on RubyWeekly.

🧩 Extensions

For each officially supported extension we need to ensure it is compatible with the new Solidus version.

Requires permission to both push to the master/main branch and to rubygems.

1. Ensure that the CI is green
2. Update the version in lib/solidus_extension_name/version.rb
3. Commit the changes with the message Release vX.Y.Z
4. Run bin/rake release (this will build, create the git tag, and push to both git and rubygems)
5. Create the GitHub release and auto-generate the changelog