Releases and versioning

This page explains how DocView Capture versions are numbered, how a release is built, and how it moves from a test system to production. It is for developers who build releases and for IT staff who install them.

One version number

The web app, the DocView Worker and the Scan Agent share one version number. It is set in Directory.Build.props:

<Version>1.2.0</Version>

Versions follow semantic versioning, MAJOR.MINOR.PATCH:

Pre-release versions use a suffix, for example 1.3.0-rc.1.

Where you see the version

• About (account menu › About and support) shows the version and the build, for example "1.2.0 · build 1205f0796c71". The build is the git commit the release was built from.
• The account menu shows the web app's version.
• Administration › DocView Workers shows each DocView Worker's version.
• When the Scan Agent on a PC has a different version from the web app, the Scan screen asks the operator to update it. See Scan Agent.

Tip: When you contact support, an administrator can click Copy for support on the About page. It copies the version, build and system details.

The changelog

CHANGELOG.md lists what changed in each release, newest first, under a heading per version (for example ## 1.2.0 — 2026-09-30). It becomes the release notes. Schema changes are listed there too, because they matter for rollback.

Day-to-day development

1. Work on a branch, for example feature/export-sftp or fix/audit-filter.
2. Open a pull request to main.
3. The CI workflow (.github/workflows/ci.yml) builds the solution and runs every test on Windows with SQL Server LocalDB.
4. Merge when CI passes.

Protect main so that pull requests and a passing CI check are required, and force pushes are blocked.

Make a release

1. Raise <Version> in Directory.Build.props, for example to 1.3.0.

2. Add a ## 1.3.0 section at the top of CHANGELOG.md.

3. Commit, tag and push:

   git commit -am "Release 1.3.0"
   git tag -a v1.3.0 -m "DocView Capture 1.3.0"
   git push origin main --follow-tags
   

4. CI sees the v*.*.* tag, runs tools/publish.ps1, and creates a release named v1.3.0 with every package and the checksums attached.

What a release contains

tools/publish.ps1 writes the release to dist/<version>/:

The programs are self-contained for 64-bit Windows, so servers do not need a separate .NET runtime. IIS still needs the ASP.NET Core Module from the .NET Hosting Bundle.

Tip: Check the download with the checksums in SHA256SUMS.txt before you install, for example with Get-FileHash .\DocViewCapture-Web-1.3.0.zip -Algorithm SHA256 in PowerShell.

Build a release on your own PC

./tools/publish.ps1                                # version from Directory.Build.props
./tools/publish.ps1 -Version 1.3.0-rc.1 -SkipTests # a release candidate
./tools/publish.ps1 -Languages eng,deu,fra         # include more OCR languages

The script warns when the working tree has uncommitted changes. Always build releases from a committed, tagged revision.

Promote, do not rebuild

Install each release first on a test system, then install the same packages on production. Never rebuild for production. This way production runs exactly what you tested.

For Azure, .github/workflows/deploy-azure.yml deploys a released version on demand to a staging or production environment. It checks the package checksums, deploys the DocView Worker and then the web app, and waits for /health/ready. See Install on Azure.

Hotfixes

To fix a released version without taking new features from main:

1. Create a branch from the release tag:

   git switch -c hotfix/1.3.1 v1.3.0
   

2. Fix the problem and raise the version to 1.3.1.

3. Add a ## 1.3.1 section to CHANGELOG.md.

4. Tag v1.3.1 and push, as for any release.

5. Merge the hotfix back into main.

Upgrades and compatibility

• The apps upgrade the database schema when they start. Schema changes only go forward, so take a database backup before every upgrade.
• Batches in progress keep the Batch Setup version they started with.
• Batch Setup files carry a schema version. Files from older releases are upgraded when imported; files from newer releases are refused with a clear message.
• After a web upgrade, operators are asked to update the Scan Agent. The new installer is inside the web package.

See Upgrading for the upgrade and rollback steps.

Related pages

• Upgrading
• Building from source
• Install on IIS
• Install on Azure