Skip to content

HIVE-REL-001: professionalize repository and prepare v1.0.0 release #105

Description

@KayzenRoot

Classification

IMPORTANT / post-V0.1 release engineering, explicitly authorized by the owner.

Objective

Professionalize the HIVE repository to the same operational standard used for KayzenRoot/gef-bootstrap, adapted to HIVE's approved architecture and ADR-019 governance, and prepare the first professional stable release as v1.0.0.

Current accepted baseline

  • Protected main: 90cc1b91b48d628dfb3e4773e1672535b4cb8991.
  • HIVE V0.1 product closure: COMPLETE.
  • Canonical checkpoint: HIVE V0.1 COMPLETE / CLOSURE SPRINT APPROVED.
  • Deterministic DoD closure evidence: 46/46 PASS, 0 FAIL, 0 UNKNOWN, HIGH/CRITICAL 0/0.
  • Current repository VERSION is still 0.0.1-bootstrap.
  • Current dashboard package metadata is still 0.0.1-bootstrap.
  • README/SECURITY/SUPPORT still contain stale bootstrap/pre-alpha language.

Release target

The professional release target is HIVE v1.0.0. This is a release-engineering/versioning promotion of the already accepted HIVE V0.1 product baseline, not authorization for new product scope. Product architecture and the immutable V0.1 acceptance lineage remain unchanged.

Professionalization scope

  1. Professional public repository presentation comparable to GEF Bootstrap.
  2. Semantic Versioning governance for 1.0.x, 1.x, prereleases and future 2.0.0.
  3. VERSION, dashboard package version and lockfile synchronized to 1.0.0.
  4. Professional CHANGELOG.md with a fully documented 1.0.0 entry and future Unreleased section.
  5. docs/releases/v1.0.0.md with highlights, install, upgrade, rollback, compatibility, known limitations, assurance and exact release lineage.
  6. Patch-note/release-note policy: every published patch/minor/major gets a versioned release-note document and changelog entry.
  7. docs/VERSIONING.md, docs/MAINTENANCE.md, docs/UPGRADING.md, and release/runbook guidance where not already covered.
  8. README updated to stable v1.0.0 positioning and current HIVE capabilities, without overstating unsupported distribution channels.
  9. CONTRIBUTING, SECURITY, SUPPORT and AGENTS aligned to the production maintenance lifecycle.
  10. Professional issue/PR templates for bugs, features/improvements, security guidance, release/maintenance PRs and evidence fields.
  11. Dependabot policy upgraded to a practical weekly grouped model for pip, npm and GitHub Actions while keeping breaking majors separately reviewable.
  12. CodeQL and dependency-review automation where compatible with the repository visibility and current GitHub capabilities, without weakening ADR-019.
  13. Deterministic release metadata validation integrated with the existing Validate gate.
  14. Release package integrity, SHA-256, release manifest/receipt/provenance and rollback metadata.
  15. Existing .github/workflows/release.yml hardened for v1.0.0 and future SemVer releases, exact VERSION/tag/release-notes coherence and evidence packaging.
  16. Optional release receipt under .engineering/ inspired by GEF Bootstrap, but using HIVE-native evidence and preserving immutable WO-024 lineage.
  17. Professional repository metadata recommendations: description, topics, About text, releases posture, security reporting and maintenance expectations. Apply automatically only where the available connector/API safely supports it.
  18. Keep main as the latest accepted stable baseline. Future 1.0.x patches and 1.x minors use governed branches/PRs and only replace the main stable baseline after exact-head acceptance.

Patch/minor/major policy

  • 1.0.x: backward-compatible fixes, security fixes, dependency maintenance, documentation corrections and bounded operational improvements.
  • 1.x.0: backward-compatible new capabilities accepted through normal HIVE governance.
  • 2.0.0: breaking public contract/schema/API/operational changes that cannot remain backward compatible.
  • prerelease suffixes such as -rc.1 may be used only when explicitly authorized.
  • tags are immutable-by-policy and must identify an accepted exact release commit.
  • accepted historical release evidence is never rewritten by later maintenance.

Out of scope

  • New HIVE product functionality merely to justify 1.0.0.
  • Rewriting or renaming the accepted V0.1 product history.
  • Changing PostgreSQL/pgvector/Redis/CAS architecture.
  • Weakening ADR-019, protected main or required checks.
  • Silently selecting an open-source license for the owner.
  • Publishing v1.0.0 before the professionalization PR, exact-head Sol audit, post-merge CI and release checks are green.

Required acceptance

  • Repository no longer presents the accepted product as pre-alpha/bootstrap-only.
  • Version metadata is coherent at 1.0.0.
  • CHANGELOG.md and docs/releases/v1.0.0.md are complete and evidence-based.
  • SemVer/release/patch/maintenance policy is explicit and testable.
  • Release metadata is deterministically validated in CI.
  • Release workflow validates exact tag/version/notes and produces checksummed artifacts without secrets/local data.
  • Release receipt records exact release commit, tag, artifacts/checksums, validation evidence, rollback guidance and immutable V0.1 lineage.
  • Professional README, contributing, security, support, issue/PR templates and maintenance docs are current.
  • Security/dependency automation is enabled where compatible, without bypassing existing gates.
  • Full validation, Integration health and Review Evidence pass on the exact PR HEAD.
  • Sol performs exact-head audit before merge and before release publication.

Release sequence

  1. release/v1.0.0-professionalization preparation branch and PR.
  2. Exact-head Sol audit under ADR-019.
  3. SQUASH merge only after all required gates are green.
  4. Mandatory post-merge CI on exact new main SHA.
  5. Create/push annotated v1.0.0 tag only from the exact accepted release commit.
  6. Existing release workflow validates and publishes the GitHub Release with release ZIP, SHA256 and review evidence.
  7. Verify release URL, tag target, assets/checksums, source archives and release metadata.
  8. Record final release receipt/provenance without rewriting accepted product history.

Stop condition

HIVE_V1_0_0_RELEASE_READY_REPOSITORY_PROFESSIONALIZED_AWAITING_SOL_AUDIT

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions