Versioning and support policy

Ignite - versioning and support policy

Learn about Ignite's versioning and support policy.

Ignite SDK versioning

MAJOR

Major Builds - Platforms

A Major version change in software is when the software undergoes significant updates that make it incompatible with older versions. This often includes major redesigns, new features, or changes to how the software works internally. For example, the introduction of Ignite was a Major build and required users to adapt their app code because the previous versions were not compatible with the new version.

Includes:

• Significant App Code Adjustments
• System Redesigns
• Architecture Changes

Estimated time to integrate into your app: Typically 1-3 weeks

MINOR

Minor Builds - Features

A Minor version change in software typically introduces new features or functionality without impacting existing APIs or compatibility. These updates enhance the software’s capabilities.

Includes:

• Login Changes
• Ticket Management Changes
• Entry Changes
• Occasionally a minor build may be deemed "REQUIRED" if it relates to the secure protection of tickets and/or accounts. Critical releases will be communicated directly for integration consideration.

Estimated time to integrate into your app: Typically 2-3 days

PATCH

Patch Builds - Bugs & Isolated Updates

A Patch version change is the smallest and most frequent update, focusing on bug fixes, security patches, and performance improvements. These changes don’t add new features or alter existing functionality. They aim to resolve issues and enhance stability without changing the software’s interface or behavior.

Includes:

• Bugs
• Adjustments for a single client, app, team, or venue
• Estimated time to integrate into your app: Typically hours-1 day.

NEW: Pre-release Candidate Releases (Pre-RC)

Pre-release candidate releases refer to builds or versions of software that are created and distributed prior to the official Release Candidate (RC) phase. These versions are generally used for internal testing, partner testing, feature validation, integration checks, and early feedback, but are not yet stable or complete enough to be considered a candidate for final release.

These builds will be identified with an "rc" tag - as an example: **"Version 1.2.3-rc.1" **

Includes:

• Unstable or Incomplete: Features may still be in development or undergoing significant changes.
• May Contain Known Bugs: The focus is on testing and refinement rather than stability.
• Not Finalized: APIs, user interfaces, and functionality can still change.
• Internal or Limited Audience: Often shared with QA teams, stakeholders, or a small group of users for feedback.
• Build Types May Include: (as examples)
  • Alpha: Very early version, typically unstable and used for internal testing only.
  • Beta: More stable than alpha, often shared with external testers or select users.
  • Dev/Canary/Nightly: Frequently updated builds used by developers or power users to test the latest changes.