Release Process

Release Process

Releases are built from tags. Pushing a tag starts two workflows:

• Release builds the CLI and web archives and publishes them on GitHub Releases.
• Docker builds and pushes the container image.

Tag format

flowchart LR
    T[git tag v2.4.x] --> R[Release workflow]
    T --> D[Docker workflow]
    R --> A[CLI archive]
    R --> B[Web archive]
    D --> G[GHCR image]

Loading

Use a version tag:

git tag v2.4.10
git push origin v2.4.10

Numeric tags such as 2.4.10 also work. Pick one form and stay consistent. The latest tags use the v prefix.

Archives

Each release gets two files:

File	Contents
MHDDoS-<tag>.zip	start.py, README, license, requirements, config, wordlists, Docker files
MHDDoS-web-<tag>.zip	the same runtime plus the web/ panel

Both archives are built from the tag commit. Anything merged after the tag is not included.

Container image

The Docker workflow publishes:

ghcr.io/matrixtm/mhddos:<tag>
ghcr.io/matrixtm/mhddos:sha-<short>
ghcr.io/matrixtm/mhddos:latest

latest is updated from the default branch. Version tags are added for semantic tags.

Manual release

You can re-run the Release workflow from the Actions tab:

1. choose Release;
2. choose Run workflow;
3. enter an existing tag.

It rebuilds the archives and replaces the assets with --clobber. It does not move the tag.

Pre-release checklist

• python start.py DOCTOR passes on a clean install.
• ruff check and ruff format --check pass.
• npm ci and npm run build pass.
• docker compose config is valid.
• The README method counts match the code.
• git status is clean.

Rollback

A tag is a fixed point. If a release is broken:

1. fix the problem on main;
2. tag the next patch version;
3. point users at the new release.

Avoid moving an existing tag. It changes what a version means and breaks checksums people may have saved.

Checksums

The Release workflow prints SHA-256 checksums in the job log. If you need them on the release page, download the archives and run:

sha256sum MHDDoS-*.zip