A cTrader cBot release is only reproducible when you can connect the source you reviewed to the compiled file you installed. Keep the source revision, build settings, .algo artifact and test notes together; a filename like final-new.algo is not a release record.
What belongs in a cBot release
The source project is the editable record; the compiled .algo is the installable output. cTrader's compilation documentation explains how Algo builds create .algo files and documents build properties that control output, copying, source inclusion and symbols. The build output is not the same thing as a version history: keep an explicit link back to the source revision that produced it.
For each release, preserve:
- The source revision and a short description of the change.
- The compiler and build configuration you used.
- The exact
.algofile delivered for installation. - The parameter values and environment used for your verification run.
- A concise result and any known limitation.
This record lets you answer a useful operational question later: which code and settings were running when that behaviour occurred?
A small release workflow
Treat a cBot update as a controlled change, not a file replacement:
- Commit the source change before building. Keep credentials out of the repository; the cBot API-key checklist covers that separate risk.
- Build from that committed revision. Give the artifact a release label that matches the revision or release tag, and store it with the build notes.
- Review the change and test the behavior that it can affect. The AI-generated cBot code review checklist is useful even when a person wrote the change: compare the diff with the requirement, then check the relevant paths.
- Install the named artifact in the intended environment. Record the configuration used; do not assume that a source commit alone captures platform parameters or account-specific setup.
- Keep the prior known-good artifact available until the new build has been checked in its actual operating setup. If you need to revert, restore the known artifact and its matching configuration rather than rebuilding an old source tree from memory.
GitHub describes a release as a version based on a Git tag, with release notes and links to downloadable files. That is a useful packaging pattern for a private cBot project too; it is a workflow suggestion, not a cTrader requirement. A tag identifies source history, while the attached build artifact and notes identify what you actually installed.
What a release record cannot prove
A clean release trail helps you reproduce a software change. It does not prove that the strategy has an edge, that a broker will fill orders the same way, or that a build is safe under every account condition. Test the exact artifact and configuration you plan to run, and keep operational safeguards separate from version labels.
If you cannot make that connection, pause the rollout and rebuild the record first. A tidy name is not evidence.