Release Process

Release Process

This page records the release routine for PICAZHU Windows. The goal is repeatable release quality: build, test, publish, package, scan, stage source, push, tag, upload assets, and update docs.

Local Build

dotnet restore .\Picazhu.sln
dotnet build .\Picazhu.sln -c Release -m:1
dotnet test .\Picazhu.sln -c Release --no-build -m:1

Publish App

dotnet publish .\app\Picazhu.App\Picazhu.App.csproj `
  -c Release `
  -r win-x64 `
  --self-contained false `
  -m:1 `
  -o .\publish\Picazhu.App-win-x64 `
  /p:DebugType=None `
  /p:DebugSymbols=false

Build Release Assets

.\scripts\Build-WindowsRelease.ps1

Expected release outputs:

• release/PICAZHU-Windows-Setup-<version>.exe
• release/PICAZHU-Windows-portable-<version>.zip
• release/SHA256SUMS.txt

Smoke Test

• Launch the published app.
• Confirm the process is responding.
• Add a folder and confirm media appears.
• Open a HEIC file if sample media is available.
• Preview image and video items.
• Export selected originals.
• Open Settings and confirm provider/theme controls are usable.
• Confirm AI defaults off on a fresh profile or clean settings state.

Security and Packaging Checks

• Confirm portable zip does not include .pdb debug symbols.
• Scan generated release assets with Microsoft Defender or another trusted scanner.
• Verify hashes in SHA256SUMS.txt.
• Do not commit installers, portable zips, logs, local databases, screenshots, recordings, or temp files to the source branch.

GitHub Staging

.\scripts\Stage-GitHubRepo.ps1

Then commit and push from the staged GitHub working tree:

git add .
git commit -m "Prepare <version> release"
git push origin main
git tag v<version>
git push origin v<version>

GitHub Release

Create a prerelease for alpha builds and upload:

• installer .exe
• portable .zip
• SHA256SUMS.txt

Release notes should clearly state:

• AI is optional and off by default.
• Installer may be unsigned until code signing is added.
• Build is alpha quality and intended for controlled testing.
• Any important fixes, limitations, or manual verification results.

Documentation Sync

After meaningful product, QA, release, or architecture work:

• update README.md if public-facing capability or install guidance changed
• update STATUS.md for current build state and known open areas
• update PROGRESS.md for milestones and lessons learned
• update DISTRIBUTION.md for packaging or release workflow changes
• update this GitHub Wiki so testers and collaborators see the current roadmap and status