Support policy

This document will constitutes the service-level agreement (SLA) between Bolt and its consumers.

Note: this should be considered a living document, and may be updated if necessary. Any significant changes that may impact consumers will be noted in the changelog.

• Supported uses
• Supported integrations
• Request process
  • Official requests
  • Informal requests
  • Issue resolution
• Releases
  • Support statuses
  • Cadence
  • Versioning

Bolt is intended to accelerate development of member-facing projects that support the Nationwide brand.

In order to be fully covered by this SLA, a project must meet the following criteria:

• The project is member-facing
• The project is intended to prominently display the Nationwide brand
• The project's architecture is compatible with Bolt's intended installation and usage
• At least one of the following is true:
  • Preferably, the project team is working alongside a designer from the User Experience & Human Centered Practices (UX & HCP) team
  • If the project team is not working with a UX & HCP designer, components must be used in accordance with all documented guidelines

While Bolt may help accelerate projects outside of its intended scope, we cannot guarantee it as an appropriate tool for other projects and may not be able to provide support in cases that do not meet the above criteria.

These platforms and technologies are verified to work with Bolt, and are routinely tested during development.

If you encounter an integration issue with any of these, please create an issue on GitHub.

• Chrome (Mac + Windows)
• Firefox (Mac + Windows)
• Safari (Mac)
• Edge (Mac + Windows)
• Safari (iOS)
• Chrome (Android)

As of October 31 2024, compatibility with Mozilla Firefox is not guaranteed.

Due to changes in Nationwide Technology policies regarding internal browser support, and subsequent removal of Mozilla Firefox from all Nationwide devices, we are no longer able to verify Bolt compatibility with Firefox on either Mac or Windows.

Bolt typically will not make changes to compatibility outside of a major version, but because this is the result of an enterprise-wide policy change, the impact is not isolated to any particular version of Bolt.

Bolt has always strived to build features and improve functionality in harmony with widely available browser APIs, and we have no intention to deviate from this principle. Statistically-speaking, even if we cannot verify compatibility with every modern, standards-compliant browser, it is likely that compatibility exists.

• Angular
  • Bolt supports integration with Angular versions that are new enough to be supported by Angular itself.
  • For more information, see the SLA for the ng-bolt project.

All Bolt components go through accessibility testing and are developed in line with WCAG 2.2 AA standards. Because each screenreader and browser combination behaves differently, Bolt developers focus on the most common and well-supported combinations, including:

• JAWS + Chrome/Edge
• NVDA + Chrome/Edge
• VoiceOver + Safari/Chrome

Occasionally, incompatibilities between certain browser and screen reader combinations will exist that are outside the scope of the design system to address. In these cases, any known issues will be noted in the accessibility tab of a component's documentation.

Consumers are encouraged to submit a bug report if issues are found that negatively impact accessibility. However, we are unable to guarantee identical behavior across all assistive technologies, and issues with specific combinations may be addressed on a case-by-case basis.

These technologies are not routinely tested during development of Bolt assets, but consumers have reported successfully using them in combination with Bolt.

The Bolt team will do its best to support projects using these technologies, however, some issues related to integration with unverified technologies may be deemed out of scope.

• Tridion

• Cypress

These technologies are specifically unsupported by Bolt, and are not recommended for use with the system. The Bolt team is unable to provide support for projects attempting to use unsupported integrations.

• Internet Explorer
  • Bolt 5.0 and newer do not support Internet Explorer.
  • Bolt 4.0 includes minimal support for IE11:
    • The basic functionality of components should work with IE11 + Bolt 4.0.
    • We do not guarantee visual parity or complete accessibility with IE11 + Bolt 4.0.
    • To support IE11 and legacy browsers, installation of Bolt 4.0 must follow the steps to include additional polyfills.

• React
  • Due to a number of known issues integrating with custom elements, we are unable to assist or provide full support for projects using React.

To formally initiate a request for support, consumers should open an issue on GitHub.

Templates are provided for the following types of requests:

• Report a potential defect (Bug report)
• Request a new component or enhancement to existing component (Feature request)
• Request support installing or using Bolt (Implementation support)

Resolution time may vary depending on urgency, magnitude of impact, and the type of request.

Defects should be reported when a component does not look or behave as expected. Defect fixes are given the highest priority and typically receive the quickest resolution of all issue types.

To be considered a defect, the consuming app

• must be using the component in accordance with all documented guidelines
• must be using a supported version of Bolt
• must be built using supported integrations

If a component is being used incorrectly, or if the project is built with unsupported or unverified technologies, the issue will be classified as implementation support.

If the app is attempting to use a component in a way that is not currently supported by the system, but would likely be a useful and broadly-applicable addition to the system, the issue will be classified as a feature request.

Feature requests are added to Bolt's product backlog, and are completed as availability and prioritization permit. To help us assess the priority of new features, we recommend consumers review existing issues, and add a comment or reaction on issues that would benefit their team as well.

Consumers who need help installing or using Bolt may submit a request for implementation support.

Before opening an issue, we request that consumers have read through all applicable documentation, including installation instructions, migration guides and documentation pages for any specific components in question.

The Bolt team will do its best to support implementation as bandwidth permits, but may be unable to assist in cases where the consuming app is using unsupported technologies, or if the request requires general front-end development assistance that is unrelated to published Bolt assets.

Those in need of implementation support may benefit the most from unofficial requests and the use of informal channels, which help to facilitate discussions with other consumers of Bolt.

For more casual questions or discussions with other consumers of Bolt, the following Teams channels are available to anyone at Nationwide:

• Bolt - NW Design System (General)
• Bolt - NW Design System (Developers)
• Bolt - NW Design System (Designers)

If you are uncertain whether a question merits an official request, you may wish to start with one of Bolt's informal channels, and create an issue on GitHub to follow up if necessary.

Questions that are raised at office hours, in Teams channels, or in messages to Bolt team members are permitted, but the formal support agreement laid out by this document does not apply unless submitted through the official request process, ie: GitHub Issues.

Issues associated with official requests will be closed when resolved, or after a certain period of inactivity.

Defects are considered resolved when an appropriate fix is available for consumption. If the defect fix is a direct result of a bug report, the associated issue may be closed as soon as the version containing the fix is published. If the Bolt team suspects that a defect has been fixed by related work, they will comment on the issue to confirm whether the latest release solves the issue. If there is no response within 1 iteration (14 days), the issue may be closed.

Feature requests are considered resolved when an associated feature is published, or if the Bolt team decides not to support the requested feature. An explanation will be provided as a comment on the issue when it is closed.

Requests for implementation support are considered resolved when the requesting team is able to use Bolt successfully, or if the request is deemed out of scope. If a Bolt team member does not receive a response from the requestor within 1 iteration (14 days), the request may be closed due to inactivity.

Beginning with Bolt 7, major releases will occur biannually (every other year) instead of annually.

Applies to: Current major release

Active support duration: Approximately 2 years (until next major release is available)

Bolt assets that are under active support will continue to receive new features, in addition to patch-level updates and defect fixes.

Applies to: Previous major release

Maintenance support duration: 1 year

Bolt releases under maintenance support will not receive new feature-level work. For teams requesting enhancements, we recommend ensuring your team will be able to consume the latest version of Bolt in order to benefit from any requested features.

Maintenance support may include patch-level releases, depending on the severity of the defect:

• Critical defects are defined as issues that are hazardous, unsafe, or insecure for the consuming app. To the best of their ability, Bolt developers will address critical defects as part of maintenance support.
• Minor defects are defined as issues that are unlikely to affect the usability of the object. Bolt developers will not address minor defects as part of maintenance support.
• Major defects are defined as issues that are likely to create failure of the unit, or a related unit, for its intended purpose. Bolt developers may address major defects as part of maintenance support, only if all of the following conditions are true:
  1. The consuming app is using Bolt as documented, for a supported use
  2. The consuming app has upgraded to the latest patch version of the major release they are using
  3. The consuming app is unable to upgrade to the latest major release of Bolt
  4. The consuming app is unable to find a workaround for the defect

Applies to:

• Releases more than one major version behind current
• Previous major version, after a newer version has been available for at least 12 months

Bolt is unable to provide support for releases older than the previous major version. For any apps still using these assets, we recommend updating to the latest version of Bolt.

In short, we plan to adhere to the following release cadence:

Releases will typically not be published on Mondays or Fridays.

Monthly releases are only published if there are updates ready, and may not occur every month.

Bolt follows semantic versioning (semver) practices.

A major release will introduce backward-incompatible changes, as compared to the previous major release (e.g., v2.0.0 assets will be incompatible with some or all of v1.x APIs.

• Major releases will require some degree of effort to modify code in your own project.
• A migration guide will be provided to document any modifications needed.
• To reduce the burden of upgrades on consumers, Major releases will occur no more than once every other year

A minor release will introduce new functionality as well as correct defects.

• Minor releases are expected to be backward-compatible with previous versions within the same major version range.
  • For example: v4.3.0 should be compatible with v4.2.x, v4.1.x, and v4.0.x APIs, but not with v3.x or earlier APIs.
• Minor releases may occur no more than once a month on the last week of each month between major releases.
  • There is no guarantee that a minor release will go out each month.
  • A minor release will only go out if there are new features to ship.

A patch release will correct defects.

• Patch releases are expected to be backward-compatible with previous versions within the same major version range.
  • For example: v4.1.1 should be compatible with v4.1.0 and v4.0.x APIs, but not with v3.x or earlier APIs.
• A patch release may occur no more than once per week.

A prerelease is similar to a major release in that it may introduce backward-incompatible changes.

• A prerelease may occur no more than once per week.
• a.k.a., "release candidate", "RC", "alpha", "beta", etc.

Breaking changes will only be included in major releases or pre-releases. A breaking change is defined as one that requires consumers of Bolt to make updates to their own code for Bolt assets to continue behaving as expected.

For example, the following would be considered breaking:

• Changes to component APIs or utility classes that are not backwards compatible
• Removal of component APIs or utility classes

While these examples would not be considered breaking:

• Changes to component appearance that do not affect layout of elements around them
• Adjustments to color token values in order to meet contrast requirements

---

• 11/20/2025 - Update major release cadence from 12 months to 24 months
• 10/31/2024 - Updates to Firefox support
• 01/19/2023 - Add explicit criteria to supported uses regarding technical compatibility with Bolt (previously explained in later sections)
• 02/28/2022 - Publishing SLA