Neural LogDocumentation
Developer reference

Neural Log Build Versions, CI Artifacts and Release Notes

Developer reference for Neural Log four-part versioning, the CI build workflow, release tags and the workflow that generates the release notes changelog.

Neural Log uses a shared four-part version, major.minor.patch.build, for every build. This developer reference explains where the version comes from, what the CI build produces, how release tags are created and how the original repository generates release notes.

Version source#

Version attributes live in CommonVersion.cs and are linked into the main projects through Directory.Build.props. Each component must be between 0 and 65534.

Local numbered builds#

python tools/set_build_version.py --build-number <build>
dotnet build NeuralLog.sln --configuration Release

Stamping modifies CommonVersion.cs in the working tree. Restore it after the build unless you are committing an intentional version change.

CI build workflow#

The Build Neural Log workflow runs on pushes to main, pull requests and manual dispatch. It:

  1. Stamps the fourth component with the workflow run number.
  2. Restores and builds the solution.
  3. Publishes the Blazor application as a versioned artifact.
  4. Includes build-version.json with version, commit and run number.
  5. Verifies that assembly, file and product versions match the stamped number.

Successful main-branch builds create a tag 1.0.0.<build>. Tags are never overwritten: a retry of the same run keeps its version, and a tag collision with a different commit fails.

Release notes automation#

The separate Publish release documentation workflow runs when a GitHub release is published, edited or deleted, and on manual dispatch. It reads all non-draft releases, regenerates mintlify/changelog.mdx without duplicates and pushes it to main. That generated file is owned by the application repository's workflow. This ChatGPT Site is a separate publication; see Documentation maintenance.