This is partly documenting the current flow, partly aspirational. Within the first few releases of NB5, this should all be standard and reliable. This notice will be removed at that time.

Release Channels

We have a three track release system:

• build artifacts are produced from every successful build on a branch.
  • build artifacts: build workflow
  • build docs: http://builddocs.nosqbench.io/
• preview artifacts are promoted to the releases section as pre-release (only) versions.
  • preview artifacts: releases
  • preview docs: http://previewdocs.nosqbench.io/
• release artifacts are eventually promoted to the releases under a proper release name and tag:
  • release artifacts: releases
  • release docs: http://docs.nosqbench.io/

This is a system of incremental promotion from build to preview to release, with documentation included. This allows us to preview new features and capabilities with the community in a safe way, only accepting previews which are up to release standards.

Repositories

Of course, managing this flow requires a few more repositories than usual, since we are hosting the docs sites on github pages. This means we need the main code repo for NoSQLBench, as well as a separate repo for each of the three docs sites:

The main repo for nb5 is at nosqlbench.io. This is just a convenient name for https://github.com/nosqlbench/nosqlbench.

This allows convenient access to issues, and pull requests too.

The three docs sites and their corresponding URLs are:

1. nosqlbench-build-docs, accessed at http://builddocs.nosqlbench.io
2. nosqlbench-preview-docs, accessed at http://previewdocs.nosqlbench.io
3. nosqlbench-docs, the main docs site, at http://docs.nosqlbenhc.io

Automation

All of the CI & CD build automation for NoSQLBench is hosted in github actions.

Release Criteria

Before a preview release can be promoted to a main release, the following must happen:

1. All high CVE alerts for potential issues must be addressed. We use multiple static analysis tools for this. Any high severity issues are required to be addressed, even if this means that they are flagged as a false positive after further review.
2. All integration test must pass.
3. New functionality must be documented in the docs site. Ideally this includes a what's new update.

Release Notifications

When a new release is made, the community should be notified in the usual places. This isn't active, yet but we intend to support:

• discord
• this docs site
• twitter and/or mastodon
• corporate sponsor sites / blog feeds

Back to top