Builds and versions
A version is the state of a strategy's own source code, compiled and kept as a complete copy you can run later. This page covers what makes a new version, what an instance is pinned to, and how old copies are cleaned up.
A version is a change in the strategy's own code
Editing the strategy and building it gives a new version. An engine or framework update does not: the engine is always the current one, for every strategy and on every path, so an update never changes which strategy code runs. The same source state compiled twice keeps the same identity, so pressing build again on unchanged code does not add a version to your pickers.
Each build is kept as a whole runnable folder: the host, the strategy's dll and the framework libraries it was built with. That folder is what makes an old version runnable at all.
How a version runs
Next to every version the pickers and the log say one of three things:
- framework current for the current version, and for an older version whose source is still kept: it is rebuilt on the current framework when it starts.
- runs as built for a version whose source is no longer kept, so it runs exactly the bytes that were compiled.
- frozen - own framework, runs as built for a frozen build, which keeps its own framework as it was at that time. A frozen build is what cleanup keeps, and it is preferred as the default pick.
A build carries an optional name you give it: a version like 1.2 and a title like before bar fix, 32 and 80 characters. Every picker then shows the name in front of the build date. The name stays with that build.
Pinning: which version an instance runs
Every paper instance, live instance and portfolio stores the version it runs. Nothing follows the newest build, so a build you did not ask for can never take over a running instance.
- A running instance keeps its exact version until you press Update on it. A new run uses the current version.
- A row without a stored version gets one, in the order: the newest frozen build, the build the live bin matches, then the newest complete folder. The serve log says which, one line per row.
- A version is never replaced silently. A missing build refuses to start and names the build it wanted.
Choosing a version
The same picker appears in the backtester's Build field, the new-instance dialog's Strategy build and the portfolio form's Build, so a build means the same thing wherever you choose one. It lists the retained versions of that strategy, with · frozen appended to a frozen one.
Cleanup
Superseded copies of the same version are removed at serve start, and the full key list is kept in each strategy's index file. A frozen build, a pinned build, a build in use and the live bin's own build are always kept, and the prune waits while a backtest, portfolio or sweep job is running.
For a one-time clean start, aurexion builds reset keeps one build per strategy, frozen builds included, and re-pins the instances that were pinned. Run it without flags first: that is a dry run and it prints what it would keep, re-pin and remove. Add --yes to apply it.
Where this shows up
The version an instance runs is echoed on its Config tab, and a run records the build it used, so a difference between two runs can be traced to the code behind it. For how a paper instance and a live one differ once they are running, see Paper versus live.