v1.7.4-rc (pre-release)

Pre-release 1.7.4-rc / tag v1.7.4-rc (candidate — not stable Docker marketing)

Kind: GitHub pre-release (non-production) — use the Set as a pre-release checkbox in the web UI, or gh release create … --prerelease.

Working version string: 1.7.4-rc in pyproject.toml (PEP 440: 1.7.4rc1 when normalized by tooling).

Published stable baseline (unchanged for customers): 1.7.3 / Git tag v1.7.3 / Docker fabioleitao/data_boar:1.7.3 + latest until 1.7.4 final publish per VERSIONING.md and release-publish-sequencing (situational rule).

---

Intent

• Signal release-candidate readiness for 1.7.4 on main (docs/tests/orchestration alignment) without treating 1.7.4-rc as the consumer latest on Docker Hub.
• Keep Hub marketing copy refresh (docs/ops/DOCKER_HUB_REPOSITORY_DESCRIPTION.md) aligned to stable semver publishes unless you explicitly advertise an RC image.

---

GitHub Release (pre-release)

After the version bump commit is on main:

git tag -a v1.7.4-rc -m "v1.7.4-rc: pre-release candidate"
git push origin main
git push origin v1.7.4-rc
gh release create v1.7.4-rc --prerelease --title "v1.7.4-rc (pre-release)" --notes-file docs/releases/1.7.4-rc.md

Web UI parity: enable Set as a pre-release; disable Set as the latest release so v1.7.3 remains the Latest stable pointer.

Verify:

gh release view v1.7.4-rc --json isPrerelease,name,url

---

Docker (optional lab tag only)

Default posture for this milestone: do not publish fabioleitao/data_boar:1.7.4-rc to Docker Hub unless you intentionally want a pullable RC. If you do, still treat it as pre-release in communications and keep latest on 1.7.3 until 1.7.4 final.

---

After v1.7.4-rc (toward 1.7.4)

1. Finish validation (CI green, operator lab evidence, release notes for 1.7.4).
2. Bump pyproject.toml to 1.7.4 (final, no suffix) on the commit you will tag.
3. Follow stable publish order: v1.7.4 tag → GitHub Release (not pre-release) → Docker 1.7.4 + latest → refresh PUBLISHED_SYNC (+ pt-BR).