Release trust
How VeloWrite Preview Releases Work
Last updated: August 7, 2026
VeloWrite is still in preview, so code changes, local builds, release assets, installer files, and the download page need to stay separate. This guide explains what users can check before downloading or updating.
What counts as a VeloWrite preview release?
A VeloWrite preview release means a versioned GitHub Release exists and its installer assets are attached for the supported platforms. A commit on the main branch is not enough. A successful local build is not enough. A GitHub Actions artifact is also not enough unless it is uploaded to the release that the download page links to.
For users, the practical rule is simple: the version on the download page should match the latest GitHub Release tag, and the installer file name should use that same version number.
Why can today's commits differ from the downloadable app?
During preview development, the website, web editor, documentation, and desktop app can move at different speeds. A documentation fix can go live on the website quickly, while a desktop installer needs a new version, platform builds, release assets, and download links before users can install it.
That distinction matters for bug fixes. For example, a PDF export fix may be present in source code after a commit, but Windows, macOS, and Linux users will not receive it until a new installer release is published.
How do I check whether I have the newest app?
Open VeloWrite Desktop and check the About panel for the installed version. Then compare it with the version shown on the download page and the latest GitHub Release. If all three agree, you are on the current public preview build.
If the website mentions a fix but your installed app still behaves like the older version, check the changelog date and the release tag. The fix may be documented as shipped in source code but not yet packaged into a new installer.
What does the download page release date mean?
The download page release date should describe the public installer assets, not every website edit. If the site receives a wording change today but the installer files were uploaded earlier, the download date should remain tied to the release assets users actually download.
The changelog has a separate Last updated field because release notes can be clarified after the installer was published. That page date tracks documentation changes, while the download card tracks installer age.
What if a fix is in code but not in the installer yet?
This can happen in a preview product. The honest answer is to say where the fix currently lives: main branch, local build, GitHub Actions artifact, or public release. Only the last one is a normal user download.
When the fix affects a user-visible desktop bug, VeloWrite should usually create the next patch release instead of leaving users to guess. That is especially true for export bugs, data safety bugs, save problems, close behavior, update visibility, and platform installer issues.
A quick checklist before downloading
Check the download page version, open the linked GitHub Release, and confirm the installer file name matches your platform. On Windows, expect SmartScreen warnings until code signing is ready. On macOS, expect Gatekeeper friction until signing and notarization are ready.
If you are testing an important fix, read the latest changelog entry before downloading. If the changelog says a fix is planned or present only in source, wait for the next installer release or use the web editor where the fix is already deployed.