Releases

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: This ensures environments receive the exact versions you tested.

​

Release list

The Releases page organizes releases into two tabs:

​

List columns

​

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): 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.