> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clickterm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Version lifecycle

> How template versioning affects SDK behavior — scheduled, effective, and superseded states.

<Note>
  **Prerequisites:** Familiarity with [templates](/product/templates/templates-overview) and the [publishing workflow](/product/templates/editing-content).
</Note>

When you publish a new template version, you must choose an **Effective at** date and time. That timestamp determines when the new version becomes visible to end users through the SDK.

<Info>
  Until the effective time is reached, the previously effective version (if any) continues to be presented to end users. A newly published version does not become current until its **Effective at** time is reached.
</Info>

## Lifecycle states

| State          | When it occurs                             | SDK behavior                                            |
| -------------- | ------------------------------------------ | ------------------------------------------------------- |
| **Scheduled**  | `effectiveAt` is set in the future         | Not served by the SDK — previous version remains active |
| **Effective**  | `effectiveAt` time has been reached        | Served to end users via the SDK                         |
| **Superseded** | A newer version's `effectiveAt` has passed | No longer served; retained for auditing                 |

## Major vs. minor versions

|                   | Major                           | Minor                                            |
| ----------------- | ------------------------------- | ------------------------------------------------ |
| **Numbering**     | 1.0, 2.0, 3.0                   | 1.1, 1.2, 2.1                                    |
| **Re-acceptance** | All users must re-accept        | Only users who haven't accepted the latest major |
| **Use when**      | Legal terms change meaningfully | Typos, formatting, non-legal clarifications      |

<Info>
  The SDK automatically determines whether to show the dialog based on version type.
  If a user accepted major version 2.0 and you publish minor version 2.1, the dialog
  is **not shown** to that user.
</Info>

## Consent lifecycle

The following diagram shows how a user's consent status transitions through the lifecycle:

```mermaid theme={null}
stateDiagram-v2
    [*] --> NO_DATA: Template becomes effective
    NO_DATA --> PENDING: Clickwrap shown to user
    PENDING --> UNVERIFIED: User accepts or declines
    UNVERIFIED --> ACCEPTED: Backend verifies (accepted)
    UNVERIFIED --> DECLINED: Backend verifies (declined)
    DECLINED --> PENDING: Clickwrap re-shown
    NO_DATA --> OVERDUE: mustAcceptBy deadline passes
    OVERDUE --> PENDING: Clickwrap shown to user
    ACCEPTED --> [*]: Terminal (until new major version)
```

<Info>
  When a new **major version** becomes effective, all users reset to `NO_DATA` for that version and must re-accept.
  **Minor versions** do not trigger re-acceptance.
</Info>

## Implications for your integration

* **Always call `ClicktermDialog.show()`** — The SDK handles the logic of whether to display the dialog or resolve immediately
* **Check consent status programmatically** — Use `GET /clickwraps/{endUserId}/status` to verify compliance before allowing access
* **Handle re-acceptance** — When a new major version becomes effective, users who accepted a previous major version will see the dialog again

<Note>
  Publishing a version alone is not sufficient. The template must also be **Enabled**
  and the version's `effectiveAt` time must have been reached.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Product Guide: Version types" icon="code-branch" iconType="light" href="/product/templates/version-types">
    Detailed guide on major vs. minor versions and lifecycle states.
  </Card>

  <Card title="Checking consent status" icon="circle-check" iconType="light" href="/dev/guides/checking-consent-status">
    Query end user compliance status via the API.
  </Card>
</CardGroup>