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

# Releases

> Package and version your decision rules for deployment.

Releases capture a point-in-time snapshot of your main branch for deployment. They provide version control, deployment tracking, and the ability to roll back to previous versions.

## What's in a release?

A release bundles your decision files into a deployable package:

<Tree>
  <Tree.Folder name="Release v1.2.0" defaultOpen>
    <Tree.File name="pricing/discount.json" />

    <Tree.File name="eligibility/loan.json" />

    <Tree.File name="risk/assessment.json" />
  </Tree.Folder>
</Tree>

This ensures environments receive the exact versions you tested.

## Release list

The Releases page organizes releases into two tabs:

| Tab       | Contents                                         |
| --------- | ------------------------------------------------ |
| Published | Production-ready releases with semantic versions |
| Draft     | Work-in-progress releases for testing            |

### List columns

| Column         | Description                               |
| -------------- | ----------------------------------------- |
| Name           | Release identifier                        |
| Version        | Semantic version (published only)         |
| Deployed to    | Environments where this release is active |
| Created at     | Release timestamp                         |
| Change request | Associated CR if created from one         |
| Actions        | Deploy, edit, delete                      |

## Creating a release

1. Click "Create release"
2. Enter release details:
   * **Name**: Descriptive identifier
   * **Description**: Change notes or summary
3. Choose release type:
   * **Publish**: Production-ready with version number
   * **Draft**: Work in progress, no version
4. For published releases, select version increment
5. Click "Create release"

### Version increments

Published releases use semantic versioning (MAJOR.MINOR.PATCH):

| Increment | When to use                       | Example       |
| --------- | --------------------------------- | ------------- |
| Patch     | Bug fixes, minor tweaks           | 1.0.0 → 1.0.1 |
| Minor     | New features, backward compatible | 1.0.1 → 1.1.0 |
| Major     | Breaking changes                  | 1.1.0 → 2.0.0 |

The dialog shows version preview: "Previous: X.X.X → New: Y.Y.Y"

## Release detail

Click any release to view:

* **Header**: Name, version, author, creation date
* **Actions**:
  * Compare - View differences from another release
  * Open Simulator - Test this release's rules
  * Deploy - Push to an environment
* **File tree**: Browse the released files

## Deploying a release

1. Open the release detail page
2. Click "Deploy"
3. Select target environment from dropdown
4. Click "Deploy"

If the environment has approval requirements, a change request may be created.

### Deployment tracking

The "Deployed to" column shows which environments have each release active. This provides visibility into what's running where.

## Draft releases

Use draft releases to:

* Package work-in-progress for testing
* Share a snapshot with reviewers
* Prepare for a future publish

Drafts don't have version numbers and don't appear in the Published tab.

### Publishing a draft

Edit a draft release and change its type to "Publish" to convert it to a versioned release.

## Comparing releases

Click "Compare" on any release to see differences from another version. This helps understand what changed between releases.

## Simulator integration

Click "Open Simulator" to test the release's rules with sample inputs. This validates the rules work correctly before deploying to production.

## Best practices

**Name releases meaningfully** - Use names that describe the changes (e.g., "Holiday Pricing Rules", "Q1 Discount Updates").

**Write descriptions** - Document what changed for future reference.

**Use appropriate version increments** - Follow semantic versioning conventions.

**Test before deploying** - Use the simulator to verify rules work correctly.

**Track deployments** - Monitor which releases are active in each environment.