chore(release): publish Mailflow 1.0.0

[Tutitoos]

Plan reference

Phase 8 — Release 1.0: final release.

Objective

Cut the first stable release only after every 1.0 acceptance gate, provider matrix, restore drill, signed artifact, and operations document is complete.

Scope

• Freeze and review release contents, version every component, generate notes, build clean artifacts, verify signatures, publish images and DMG, update digest-pinned Compose, create the v1.0.0 tag and GitHub release, and run post-publication smoke tests.

Tasks

• Define reproducible inputs, outputs, identities, and rollback procedure.
• Implement the scoped build, deployment, validation, or documentation capability.
• Add automated checks and an isolated acceptance drill.
• Record exact digests, signatures, provenance, and operator commands where applicable.

Acceptance criteria

• All Phase 0 through Phase 8 milestones are complete with no unresolved release blockers.

• main and the v1.0.0 tag identify the reviewed release commit.

• Published artifacts, digests, signatures, SBOMs, provenance, notes, and installation files agree.

• Fresh install, upgrade, backup, restore, rollback, web, macOS, Google, Microsoft, and iCloud or IMAP smoke tests pass.

• Secrets and private mail content never enter artifacts, logs, crash data, fixtures, URLs, screenshots, or release metadata.

• The work is independently reviewable, reproducible, and rollback-safe.

Validation

• Execute the complete release checklist from a clean checkout and empty deployment target.

• Verify the public release, GHCR manifests, DMG, signatures, docs, and post-release CI.

• Run make check plus the affected native, container, integration, accessibility, security, install, upgrade, or restore suites.

• Record exact artifact identities and use sanitized evidence.

Dependencies

Blocked until every preceding 1.0 milestone and release issue is complete: https://github.com/Tutitoos/mailflow/milestone/9

Risks

Release automation can publish unusable or unverifiable artifacts and operational mistakes can lose data. Require immutable identities, clean builds, signature verification, restore drills, and documented rollback.

Out of scope

• iPhone, iPad, Android, SaaS, promotion, and post-1.0 productivity features.

[Tutitoos]

Dependency audit — 2026-09-09

The repository-side prerequisites are complete: issues through #73 are closed, Phase 0 through Phase 7 milestones are closed, PR #129 is merged, and CI/Security are green on main at 75bdeedf3658d6be4a8ce5a2299f3b3b845dc461.

Publication remains blocked by protected release evidence that cannot be synthesized in source control:

• No Developer ID Application signing identity is available in the configured user or system keychains (development/distribution identities do not satisfy the notarized direct-download contract).
• The desktop-release GitHub Environment currently has zero secrets and zero variables; the workflow therefore cannot import its Developer ID certificate, authenticate notarytool, or sign the updater.
• No Mailflow notarytool keychain profile exists locally.
• The protected Google, Microsoft and IMAP timing matrix has not been run with dedicated real-provider accounts.
• Fresh-install, upgrade, backup/restore and rollback smoke evidence on the target host is still required.

Per docs/git-workflow.md, no release branch or v1.0.0 tag will be created while the issue is blocked. After those protected inputs exist, remove status:blocked, create release/74-publish-mailflow-1-0-0 from the then-current origin/main, execute the complete checklist, and publish only if every gate succeeds.