Release Versions

A Release Version is a Project’s canonical release record. It identifies planned scope and a release decision. It does not represent a deployment to an environment. A Work Item can belong to more than one Release Version, such as when a fix ships in two maintained versions. Only versions from the same Project can be assigned to its Work Items.

Plan and release

Open a Project’s Releases page to create a version with a unique name, optional display version and description, owner, and target date. Versions start as Planned. Move one to In progress while work is underway; move it back to Planned if needed. The release page shows the current Work Item scope, completed and incomplete counts, and filters for type, status, and priority. These counts describe planned and completed Work Items, not deployed software.

When you mark a version Released, Hamstik captures its original Work Item scope and the first release time. If work remains incomplete, Hamstik shows the count and asks for an explicit acknowledgement. This is a release decision; an announcement is optional. Archive a version when it should leave active planning lists. Archived versions and their history remain readable, and a manager can restore one.

Project managers manage Release Versions and release decisions. Work Item editors can assign active versions during Work Item creation or editing, or use the Work Items list to add, remove, or replace memberships in a batch. Correcting the membership of an already released version requires management access, confirmation, and a reason. The correction is recorded; it does not rewrite the first release scope.

Publish an announcement

Open a Release Version’s Announcement page and generate a draft from its current Work Items. The draft contains the version metadata and a categorized list of keys and titles. A manager can edit the introduction and highlights, reorder categories, and choose which Work Items to include without editing the Work Items themselves. The page identifies items added, removed, or changed since the draft was generated. Refresh the draft after reviewing those changes before publishing.

Publishing stores a fixed revision of the rendered Markdown, Release metadata, and Work Item list. The current announcement has a stable URL inside Hamstik; prior revision URLs remain available. Republishing creates another revision. Later Work Item edits or membership corrections never change a published revision. A manager must explicitly confirm an empty announcement. Drafts are limited to 10,000 Work Items; Hamstik rejects a larger draft instead of silently leaving items out. A published revision can be downloaded as Markdown. Access to announcements follows Organization and Project permissions; there is no anonymous public announcement URL.

Every Project starts with this basic Release workflow. Release evidence reports, readiness approvals, and environment promotion rules are separate optional Project choices. A Work Item’s completion or a Release’s Released state is not proof that a build passed checks or was deployed.

Review delivery readiness

Open a Release Version’s Readiness and approvals page to inspect builds from repositories selected for the Project. Project managers can link a provider-synchronized build to the canonical Release Version. Its source run, workflow, result, observation time, and artifacts remain visible. Disconnects, missing runs, pending checks, failed checks, expired artifacts, and stale results are shown explicitly. Linking a build does not change the Release’s state or prove deployment. If a provider later changes a linked build or its artifacts, the Release audit history records the earlier and updated evidence with the provider source. Timestamp-only syncs do not add an audit event.

The Project readiness policy starts Basic, with no required external checks or reviews. A manager may select Governed, choose required repository workflows, set evidence freshness, require reviewer decisions, and enforce a different reviewer from the Release owner or creator. Policy changes are versioned and apply prospectively. Reviewers record approvals with reasons; the decision binds to the Release revision, chosen build and artifact, and the exact evidence digest. Evidence or Release changes require a new approval. Reviewers may revoke their own decisions. A Project manager can record an explicit, reasoned override; it remains labeled Overridden and is never displayed as a passed check. Readiness may also be Fail, Pending, Stale, or Unknown. Basic readiness is Pass because no checks are required, even when no provider is connected. Readiness governs promotion only when the target environment is set to Governed. Changing a Release Version to Released follows the separate Release governance profile and does not by itself attest to check or approval evidence.

Track deployment environments

Open Project → Releases → Deployment environments to define named destinations such as development, staging, and production. Each environment starts with a basic promotion policy. A manager can opt into governed promotion, which evaluates the current Project readiness policy for that Release and environment. Optional UTC day and time windows restrict when a successful promotion may be recorded.

Managers record the outcome of a deployment attempt after it occurs. Hamstik does not start the provider deployment from this form. A record identifies the canonical Release Version, target environment, actor, time, outcome, reason, optional linked build and artifact, prior and resulting deployed versions, and the policy decision. A failed or blocked attempt leaves the current deployed version unchanged. A rollback adds another immutable event that restores the immediately preceding deployed version; it never rewrites the earlier event. Governed rollbacks are evaluated against current readiness and may require an explicit override.

The environment page shows the last successfully recorded deployed version, attempt history, current evidence freshness, and linked Milestones. A Work Item is listed as deployed only when the successful deployment has an exact build-to-Work-Item association. Otherwise deployed Work Item scope is Unknown. A Release assignment alone never marks a Work Item deployed. Provider runtime health is also unknown unless separately observed. On the Project Work Items list, use Deployed in to show only Work Items verified against the current successful deployment in an environment. If its deployed scope is unknown, the filtered list stays empty and explains why.

For automation, see the Release Version API and SqueakQL Release Version fields.

Move Release data between Projects

The Releases page downloads a ZIP bundle containing release-versions.csv, work-items.csv, and manifest.json. Both CSV files use export-local IDs; each Work Item’s Release Version IDs JSON cell is an escaped JSON array. Names containing commas, semicolons, or quotation marks therefore remain unambiguous. Empty Release Versions are included in their own file. The bundle carries the original first-release scope, when one exists, as a JSON snapshot. It does not carry the complete event history, attachments, comments, or announcement revisions; use the native archive for a broader backup.

An Organization administrator can import a bundle into a selected Project and must choose Create new versions or Match existing versions by name. Create rejects any conflicting name or display version. Match requires every definition to match a version in the destination Project; adding membership to a released version requires a reason and explicit correction confirmation. The importer creates Work Items and assigns versions within one transaction. Invalid or unresolved rows fail the whole bundle; nothing is partially imported. It does not attach Work Items across Projects. The ZIP upload limit is 64 MiB, and bundles support up to 10,000 Release Versions and 100,000 Work Items. For larger Projects, use the native archive. A standalone Work Items CSV remains available for older workflows but cannot preserve empty Release Version definitions. A vendor CSV milestone column still maps to Sprint, not to a Release Version or Organization Milestone.

For optional governed release requirements and immutable evidence packages, see Release audit reports.