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.

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.

Beta Builds

A Beta build is a more polished pre-release version of the software that follows internal or limited alpha testing. It represents a near-complete version where most core features are implemented, but refinements and bug fixes are still ongoing. Beta builds are used to gather broader feedback, validate performance at scale, and ensure feature readiness before moving to Release Candidate.
These builds will be identified with a "beta" tag – for example: "Version 1.2.3-beta.1" along with a visual beta badge:

Includes:

• Feature Complete (Mostly): Core features are implemented, though some enhancements or optimizations may still be pending.
• Known & Unknown Issues: Stability is higher than pre-RC builds, but bugs and usability issues are still expected.
• Feedback-Oriented: Shared with a broader group (partners, external testers, early adopters) for validation.
• APIs & Interfaces Close to Final: Major changes are less likely but still possible based on feedback.

General Availability (GA Build)

Description:
A General Availability (GA) build is the official, production-ready release of the software made available to all users. It has passed Beta and RC phases, undergone full validation, and represents the finalized, stable version of the product. GA builds are considered reliable for production environments.

These builds are identified with a standard version number (no suffix) – for example: "Version 1.2.3"

Includes:

• Stable & Production-Ready: All major features are complete, tested, and validated.
• Resolved Critical Issues: Any major bugs found in Beta/RC phases have been addressed.
• Long-Term Support: Eligible for standard maintenance, patches, and incremental updates.
• Widest Audience: Released broadly to all customers and environments.

Supported SDK, OS, and Device Matrix

Versioning Policy

• Minimum Supported SDK Version: v3.10.x
• Target SDK Version: Always the latest published version
• OS Deprecation Policy: Support for OS versions may be dropped 1 year after vendor EOL
• Device Support Lifecycle: Follows the OS and SDK compatibility

Best Practices for Integrators

• Always use the latest SDK version to ensure optimal performance and security.
• Test across the most common OS versions in your region.
• Check release notes for any breaking changes tied to OS or device support.

Update Frequency