Historical release documentation: These instructions describe the PyPI handoff before it occurred. Current PyPI releases install the Go CLI after the version break; older pinned releases are the Python implementation. See installation.

Markata v0.14.0

Release preparation. These are the human-readable notes for the proposed v0.14.0 Go release. Do not call this version published until the v0.14.0 tag, GitHub release artifacts, container images and (separately) PyPI wheels have been verified. The last verified GitHub release before this work was v0.13.0 (October 2, 2026).

Markata is a plugin-driven static site generator written in Go. v0.14.0 is a substantial 0.x release, not 1.0. It gathers the work since v0.13.0, including the completed repository-name handoff, the preferred markata command, new editorial layouts, faster rendering and more dependable operations.

Highlights

One Markata name, without abandoning existing users

• The canonical Go repository and module are now github.com/WaylonWalker/markata; the original Python implementation lives at markata-py.
• The preferred executable is markata. The legacy markata-go executable remains available. GoReleaser produces both executable/archive families; published container workflows retain the markata-go registry alias.
• Existing markata-go.toml, [markata-go] and MARKATA_GO_* contracts remain supported. Do not rename configuration files or TOML sections yet. Canonical MARKATA_* configuration overrides are being added with documented precedence.
• The installer, documentation and Go module now reference the canonical repository. Legacy pinned Go module consumers should not mix old and new module paths in one build.

Editorial archive and images

• Magazine-inspired editorial feeds: weekly groupings, a more useful lead-story/photo layout, cohesive weekly photo essays, native Older/Newer pagination and relative week labels.
• Less unnecessary first-paint work: deferred offscreen weeks and cards, delayed optional controls, smaller media previews and selective font preloads.
• A paginated image library can render a bounded first page and load other pages on demand for global search and filtering; native navigation still works without JavaScript. This pagination is opt-in.
• The image library inherits the site's palette, typography and aesthetic settings instead of appearing to use a separate theme.
• Improved responsive image selection, cache and feed rendering behavior.

Reader, themes and accessibility

• Reader improvements for Lobsters, Lemmy and Reddit discussion links, local subscription management, and responsive Ghost CDN previews.
• Sidebar states remain visible after CSS purging; a fallback keeps the drawer operable when optional JavaScript fails.
• Smoother, quieter view transitions, more stable startup layout, responsive header preferences and restored theme switching.
• Better admonition contrast and more careful media and calendar interactions.

Agent and builder workflows

• markata triage creates an environment-aware diagnostic handoff for an agent, stdout or clipboard.
• Builder Admin exposes revision/build provenance and distinguishes a running new builder from an actually rebuilt site.
• A new production builder revision can automatically queue a fresh site build. Retained workspaces and improved incremental releases reduce avoidable copy/promotion work.
• Expanded documentation, agent skill setup and release packaging: canonical and legacy binaries, signed checksums and SBOMs.

Install or upgrade

For a verified published v0.14.0 release:

# Version-pinned installation (Linux/macOS)
MARKATA_VERSION=v0.14.0 bash -c 'curl -fsSL https://raw.githubusercontent.com/WaylonWalker/markata/main/install.sh | bash'

markata version
markata-go version

You can also download the exact markata_0.14.0_<platform> or markata-go_0.14.0_<platform> archive from GitHub Releases. Verify against checksums.txt and the published signatures. Use a fresh install directory if another application already owns markata.

For Go installs:

go install github.com/WaylonWalker/markata/cmd/[email protected]
markata version

PyPI is a separate publication. The markata PyPI distribution historically installs the unrelated original Python implementation. A new 0.14.0 upload would deliberately transfer the latest PyPI installer to the Go executable; it is not a Python API-compatible library. Do not advertise pip install markata for Go until the wheel workflow, protected PyPI environment, trusted publishing and clean-venv install have all succeeded. See Go binary wheels and the Python handoff.

Compatibility and cautions

• Remains in 0.x. Avoid promising a stable 1.0 API or an automatic migration of Python plugins.
• Preserve markata-go.toml, [markata-go], and the legacy MARKATA_GO_* environment variables in existing sites.
• Existing v0.13.0 archives used markata-go filenames. v0.14.0 releases must verify both archive formats; do not invent filenames in installers.
• Opt-in image-gallery pagination, HTML edge caching, native navigation and Build DAG behavior must remain opt-in when the site has not selected them.
• A green Docker workflow proves an image was published, not that Argo reconciled the chart, Builder Admin rebuilt the site, or public HTML is new.
• PyPI publishes eight platform wheels with platform-specific availability. An unsupported machine can select an old Python version unless installation constraints are checked.

What to validate

1. All CI shards, including cold-vs-warm output determinism, are green on the tagged source. Investigate failed CDN-dependent fixture downloads instead of overriding tests.
2. The canonical Go module, both CLI entry points, goreleaser check and snapshot archive contents pass. Verify checksums, signatures, SBOM files and exact binary version/commit.
3. Tagged Linux amd64 and arm64 builder, fetch and search images resolve from GHCR; compare canonical and legacy image aliases.
4. On the canary: render homepage, editorial archive, image library, reader and no-JS pagination; test light/dark themes, sidebar fallback, search and cache behavior.
5. For every deployed site, independently verify: GitOps chart revision; all applicable image tags/digests; Builder Admin executable revision; latest successfully published build revision; healthy public site. A new pod alone does not complete rollout.
6. Exercise a rollback to the prior immutable known-good chart/image revision if a full build or smoke test fails.

See release and homelab rollout procedure for the exact matrix, deployment order, required gates and rollback method.

Source comparison: v0.13.0...main. After tagging, use the immutable v0.13.0...v0.14.0 comparison.