Releases
Forge releases the Figma design kit and the public @jack-henry packages — jh-elements, jh-tokens, and jh-icons — together under the same version number, along with design tokens and documentation. Version 2 in Figma corresponds to Version 2 in code.
Versions
| Version | Status | |
|---|---|---|
| Version 2 | Current | You're reading the Version 2 docs |
| Version 1 | Previous | Browse the Version 1 docs |
Version 1 documentation remains available. New components, features, and design kit updates land in Version 2 only.
Release cadence
The jh-* packages and the Figma design kit target a two-week release cycle and go out together. Dates shift when a release falls on a holiday or a pull request holds the release back.
Major releases are the exception. They run through a pre-release cycle and reach the public once the scope has stabilized. Pre-releases don't follow the two-week cycle.
Release types
| Type | What it contains |
|---|---|
| Major | Breaking changes and larger updates, planned in advance. Ships after a pre-release cycle and includes a migration plan. |
| Minor | New features and bug fixes. No breaking changes. |
| Patch | Bug fixes only. |
| Hotfix | An emergency patch for a severe, blocking bug. Ships as soon as the fix is ready. |
| Experimental | A feature or package released outside the normal cadence, versioned independently, so we can iterate without disrupting stable packages. |
How we version
Forge follows Semantic Versioning: MAJOR.MINOR.PATCH.
| Release type | Increment when |
|---|---|
| MAJOR | An incompatible change of any kind is introduced. Typically a breaking change. |
| MINOR | Functionality is added, or a change is made that doesn't break compatibility. This is the most common increment. |
| PATCH | A bug is fixed, including a hotfix, without breaking changes. |
Pre-release versions append a package number that increments with each publish: 2.0.0-64, 2.0.0-65, 2.0.0-66. While a release is in a pre-release state, the minor and patch numbers hold steady.
Release phases
A release moves through phases at the discretion of the design system team, based on scope completion, testing results, and accessibility review. For a major release, only features that have reached alpha or higher are included.
| Phase | What it means |
|---|---|
| Alpha | Unstable and possibly incomplete. Not tested for integration issues, not suitable for production. Documentation may be minimal. For previewing technical changes. |
| Beta | Feature-complete and more stable, but may contain bugs. For early adopters who want features ahead of GA. |
| Release candidate | Stable and in a final round of testing. Ships publicly if no showstoppers are reported. |
| General availability | Code-complete and ready for production. Remaining minor bugs are backlogged. Future changes follow the versioning process above. |
Breaking changes
A breaking change is any change that requires you to update your application for it to function or appear as expected. That includes:
- Deprecating tokens, properties, events, or components
- Renaming any part of a component's public interface — its tag name, an attribute, a property, or an event
- Style changes to spacing, color, or typography
Breaking changes always result in a major version increase and always ship with a migration plan.
Deprecations
When we identify a feature to remove, we announce the deprecation in a minor release and, where a replacement exists, provide guidance for moving to it. That gives you time to migrate before the removal lands in a major release. We give as much notice as we can.
What changed
| Assets | Where to look |
|---|---|
| Component code | Changelog on GitHub |
| Figma design kit | Design kit release notes |
Before you upgrade
- Review the changelog across the full version range you're moving through, not just the target version.
- For a major upgrade, start with the migration plan.