Release Schedule

Tokaido is an open source hosting platform for Drupal. The various Docker images we use in Tokaido are running in both production and non-production systems, principally at Ironstar but also at some other hosting providers.

For this reason, we want to make certain that new Tokaido platform changes get tested well in multiple environments before we ship them into production. For this reason, each Tokaido image is available in three main releases:

• Stable
• Edge
• Experimental

All updates start in the experimental stage. Uses running Tokaido locally can opt-in to the experimental release set by running tok config-set tokaido stability experimental . This release set is where we are actively developing and testing new features.

When we are satisfied that the experimental release is ready, we tag it with a semantic version number (such as 1.3.2) and then merge those changes into the Edge release. Tokaido local environments run edge by default, so these release get a lot of testing.

At Ironstar, we also run the edge release set in our customer's non-production environments for approximately up to one month. So as you can see, releases in edge get a lot of testing before being promoted.

On the second-last Monday of every month, we freeze our edge releases. That is, we don't make any more changes to this release train and begin to perform our most rigorous testing and validation.

Finally, on the last Monday of every month, we merge our stable edge release into the stable branch for each image. Basically, the last Monday of every month is when Tokaido gets a new set of production images, these are also deployed to the Ironstar production environments with the customer's last deploy (unless they've opted out of the next release).

Locally, Tokaido users can opt to only run the stable release set by running tok config-set tokaido stability stable, and they can revert back to the default by running tok config-set tokaido stability edge

Version Numbers

Each Tokaido image has it's own version number that uses the semantic version numbering schema (that is, major.minor.patch). Each version is recorded as a tag in the image's Git repository, and each version number begins in the experimental stage is progressively promoted towards production.

As an example, consider our Tokaido PHP 7.2 Docker image, which is available at tokaido/php72. This docker image has three main release sets, as we discussed above:

• tokaido/php72:stable (released on the last Monday of every month)
• tokaido/php72:edge (secured/embargoed on the second-last Monday of every month
• tokaido/php72:experimental (actively developed all the time)

During the development of an experimental release, we would create a new version tag in Git when our release is ready. For example, 1.3.0.

The tag is pushed to Git and is then available as the Docker image tokaido/php72:1.3.0 . When we're confident that this version doesn't break anything, we merge the tag into the 'edge' branch in Git and release that.