Initial Steps

The initial phase of the release process consists of

• Locking the repository for merges
• Ensuring all code is up to date
• Ensuring the current code runs properly
• Preparing the Release Documentation

When this is all done, we can stamp and tag the release.

Locking Repository

While doing the initial steps of the release process, at least up to the tagging release stage, we need to ensure that no commits/merges are created against the release branch and the main branch, except where necessary for the release.

Message all developers who have merge privileges using the Skype Dev Chat channel, and then lock the branch you are building. Go to the branches page and set a branch protection rule. If there is no branch protection rule for the branch you are building, add one. Click on the checkbox for Require a pull request before merging then set the required approvals to 6, and the branch will be effectively locked.

Updating Code

Before tagging a release we need to:

• Ensure code is up to date.
• Be sure the versioning file changes you did in the prior steps are checked in and merged. If they weren’t, remember you will have to bypass merge protections since the branch has been locked for merges.
• Update the Documentation Website to ensure that it reflects changes that have happened within the release. (Focus on the What’s New page; it’s easier to build the Changed Files page once the build is complete.)

Testing Prior to the build

Create a new shop using the branch you are about to build, and run through some tests. You want to be confident that what you’re building will work.

Hopefully you have been testing up until now and have not introduced major changes right before the build. This will give you a much greater chance of success.

Release Documentation

The Documentation Website contains details of changes between versions and general installation instructions.

The 2 main pages that need adding/updating are the What’s New and Changed Files pages. Note: The above links give examples of previous releases.

You will need to have checkout of the Zen Cart documentation website and be able to use the Hugo system to edit and test the pages locally before pushing changes,

While previously we would duplicate content in the /docs folder of the release and on the https://zen-cart.com/docs folder, these now redirect to the documentation website.

There is a final piece of documentation which needs to be updated, and that is the Implementation Guide. This is delivered as part of the build, so it must be up to date before you do the build!