| name | release |
| description | Release procedure for Fix compiler. Use when: preparing a new version release, bumping compiler version, running release checks, publishing a tagged release. Covers version bumps, doc generation, performance testing, license updates, and git tagging. |
Fix Compiler Release Procedure
When to Use
- Preparing a new version release of the Fix compiler
- Running pre-release checks (tests, performance, documentation)
- Publishing a tagged release to the repository
Prerequisites
cargo-about installed (cargo install cargo-about)- The
fix command must be buildable with cargo build --release
Procedure
Step 1: Set Compiler Version in Cargo.toml
Edit Cargo.toml at the project root. Update the version field under [package]:
[package]
version = "X.Y.Z"
Important: For pre-release versions (alpha/beta), do NOT put the pre-release suffix in Cargo.toml. The semver crate's VersionReq::STAR (*) does not match pre-release versions, which would cause all projects with fix-version = "*" to fail. For example, for a v1.3.0-beta.2 release, keep version = "1.3.0" in Cargo.toml. The pre-release designation is only in the git tag.
Step 2: Sync std-doc Version
The std-doc version must match the compiler version in Cargo.toml (i.e., without any pre-release suffix). Update these two files:
-
std_doc/fixproj.toml โ Update the version field:
[general]
name = "std-doc"
version = "X.Y.Z"
-
std_doc/Std.md โ Update the version in the header line:
Defined in std-doc@X.Y.Z
Note: This file is regenerated by test_generate_documents in Step 6, so updating fixproj.toml is sufficient if you run that test. But verify the output matches after generation.
Step 3: Verify WRITE_LOG is Disabled
Check src/tool/log_file.rs and confirm:
pub const WRITE_LOG: bool = false;
This must be false for release builds. If it is true, change it to false. Releasing with WRITE_LOG = true would cause the compiler to write debug logs during normal use.
Step 4: Run Full Test Suite
fix clean && cargo test --release
fix clean removes the .fixlang/ build artifact directorycargo test --release runs all unit and integration tests in release mode- All tests must pass before proceeding
Step 5: Run Speed Test
Run the speedtest to check for performance regressions:
cd benchmark/speedtest
fix run
Compare the output against previous entries in benchmark/speedtest/log.csv. Look for significant regressions in execution time or resource usage.
Optionally, record the result in log.csv with the current commit hash for future comparison.
Step 6: Generate Documentation
Run the test_generate_documents integration test:
cargo test --release test_generate_documents
This test:
- Installs the
fix command
- Runs
fix docs -m Std -o . in the std_doc/ directory
- Regenerates
std_doc/Std.md with current API documentation
This test must pass. If it fails, stop the release process and fix the issue before proceeding.
After running, verify that std_doc/Std.md has been updated with the correct version and content.
Step 7: Update Open Source License Page
Use cargo-about to regenerate the third-party licenses HTML:
cargo about generate third-party-licenses/about.hbs > third-party-licenses/third-party-licenses.html
Review the generated third-party-licenses/third-party-licenses.html for completeness. The accepted licenses are configured in about.toml.
Step 8: Update CHANGELOG.md (for stable releases)
If this is a stable release (not alpha/beta), update CHANGELOG.md:
- Replace the
[Unreleased] header with the version and release date:
## [X.Y.Z] - YYYY-MM-DD
- Add a new empty
[Unreleased] section above it for future changes.
Step 9: Review Changes
Before committing, show the diff for the user to review:
git diff
Present the diff to the user and wait for approval before proceeding to commit, tag, and push.
Step 10: Commit, Tag, and Push
-
Commit all changes:
git add -A
git commit -m "Release vX.Y.Z"
-
Create a tag with the v prefix:
git tag vX.Y.Z
-
Push the commit and tag:
git push
git push --tags
Checklist Summary
