Tingg

h1. Release Management Process (Mandatory)

*Applies to all Tinggit products managed in Redmine*  

*Defines how customer-facing value is planned, delivered, tracked, and audited*

{{toc}}

---

h2. 1. Purpose

The Release Management Process defines how Tinggit:

* Packages completed work into customer-visible releases

* Preserves a clean, auditable release history

* Separates business value from deployment mechanics

* Handles partial releases, hotfixes, and rollbacks safely

* Produces accurate and trustworthy release notes

This process ensures that **every release can be explained, audited, and traced** long after deployment.

---

h2. 2. Scope

This process applies to:

* All Tinggit products and websites

* All customer-facing releases

* All issues assigned to a Release Version

* All teams contributing to a release (Product, Engineering, QA, DevOps)

---

h2. 3. Ownership & Roles

|*. Role |*. Responsibility |

| Product Owner | Defines release scope, approves readiness, owns release notes |

| Engineering | Ensures implementation is complete |

| QA | Validates quality and acceptance |

| DevOps | Deploys and provides deployment traceability |

| Scrum Master | Ensures process compliance (where applicable) |

---

h2. 4. What a Release Is (and Is Not)

h3. 4.1 Release Definition

A Release represents:

* Business value delivered to customers

* A contractual or communicable product increment

* A permanent historical record

h3. 4.2 What a Release Is NOT

A Release is NOT:

* A sprint

* A deployment pipeline

* A build number

* A service or UI version

* A rollback or retry of the same event

*bq.* A release answers *“What value did customers receive?”*  

It does NOT answer *“How was it deployed?”*

---

h2. 5. Release Versions in Redmine

Release management uses **Redmine Versions**.

|_. Element |_. Purpose |

| Release Version | Defines the scope of a product release |

| Release Notes | Customer-facing summary |

| Deployment Reference | Traceability to CI/CD |

Rules:

* Release Versions are permanent

* Release Versions are never reused

* Only completed and deployed work belongs to a Release Version

* Sprint Versions and Release Versions must never coexist on the same issue

---

h2. 6. Release Naming Standards (Mandatory)

Release naming must follow:

<pre>

Release X.Y – Short Theme

Release X.Y.Z – Hotfix

</pre>

Examples:

<pre>

Release 2.5 – Career Expansion

Release 2.5.1 – Hotfix

Release 2.6 – Platform Reliability

</pre>

Forbidden:

<pre>

Release Final

Release Test

v2-final-final

</pre>

---

h2. 7. Release Planning

h3. 7.1 Identifying Release Candidates

Release candidates come from:

* Completed sprint work

* Approved backlog items

* Compliance or contractual commitments

Only items that are:

* Fully implemented

* QA verified

* Accepted by Product Owner  

may be considered for release.

---

h3. 7.2 Assigning Release Version

For each accepted issue:

|*. Field |*. Action |

| Fixed version | Set to Release X.Y |

This assignment defines **official release scope**.

Issues without a Release Version are **not part of the release**, even if deployed.

---

h2. 8. Release Readiness Validation

Before deployment, the following must be true:

* All issues in Release Version are Done or Closed

* No open blockers remain

* QA sign-off is confirmed

* Release notes draft is prepared

Saved query used:

*Release – NOT Ready (Blockers)*

If this query is not empty, **release must not proceed**.

---

h2. 9. Deployment & Traceability

Deployment execution happens outside Redmine.

After deployment:

* DevOps provides:

  * CI/CD pipeline link

  * Deployment reference URL

* Product Owner ensures:

  * Deployment reference is added to release issues

  * Release Version reflects deployed scope only

*bq.* Redmine references deployment truth — it never owns it.

---

h2. 10. Release Notes (Customer-Facing)

Release notes are derived from Redmine issues.

They must include:

* Release name and date

* Highlights (top value delivered)

* Features (Stories)

* Bug fixes

* Known limitations (if any)

They must NOT include:

* Commit hashes

* Service or UI versions

* Infrastructure details (unless user-impacting)

Release notes are owned by the Product Owner.

---

h2. 11. Release Close Process

Once deployment and communication are complete:

* Release Version status is set to Closed

* Stakeholders are notified

* Post-release bugs are logged separately

Detailed checklist:

* [[Release Close Process]]

---

h2. 12. Partial Releases

h3. Scenario

Some planned items are ready, others are delayed.

h3. Correct Handling

* Release Version includes only:

  * Accepted

  * Deployed items

* Delayed items:

  * Do NOT receive the Release Version

  * Remain in backlog or future sprint

This ensures:

* Honest release notes

* No ambiguity about delivered value

---

h2. 13. Hotfix Releases

Hotfixes are handled as **separate patch releases**.

Rules:

* No Sprint Version is used

* A new Release Version is created:

<pre>

Release X.Y.Z – Hotfix

</pre>

Issues are:

* Tracked independently

* Deployed immediately

* Closed after deployment

Detailed handling:

* [[Edge Case & Exception Handling]]

---

h2. 14. Rollback Releases

Rollbacks do not modify history.

Correct handling:

* Do NOT reopen completed issues

* Create new Bug issues

* Assign a new Release Version:

<pre>

Release X.Y.Z – Rollback Fix

</pre>

Rollback is recorded as a **new event**, not a rewrite.

---

h2. 15. Metrics & Auditability

Release-level audit questions that must always be answerable:

* What was released?

* When was it released?

* Why was it released?

* What issues were included?

* Where is the deployment evidence?

These answers are derived from:

* Release Version

* Issue history

* Deployment reference links

* Release notes

---

h2. 16. Common Mistakes to Avoid

* Using Sprint Versions as releases

* Reusing release versions

* Including incomplete work in a release

* Editing release scope after closure

* Treating deployment retries as releases

---

h2. 17. Governance Rules (Non-Negotiable)

* Every release must have a Release Version

* Every release must have deployment traceability

* Every release must be closed explicitly

* No release history may be rewritten

* Exceptions must be documented

Violations must be escalated to Product Leadership.

---

h2. 18. Final Statement

The Release Management Process ensures that Tinggit can:

* Communicate value clearly to customers

* Maintain long-term trust in metrics

* Pass internal and external audits

* Handle emergencies without chaos

* Scale product delivery responsibly

*This process is mandatory for all releases.*