This page includes information about how to get help with React Spectrum, how to report issues, and our development roadmap.

Getting help#

The best place to ask questions and get help with React Spectrum is on Github. If you have a idea, suggestion, or want some help with any part of the library, please start a discussion. The fastest way to get a useful response is to include a code example that demonstrates your question, and as much context as you can about your application. Code Sandbox is a great way to share these running examples so that the core team and the community can play around with your scenario and better understand your question.

We try our best to reply to questions as quickly as possible, but also rely on help from the community. If you see a question and know the answer, please don't hesitate to reply yourself. This helps reduce the number of questions the core team needs to answer and improves response time. Thanks in advance for your help!

Reporting issues#

Please see our contributing guide for information about how to report bugs or security issues, and request features. Please check the existing issues on GitHub before filing a new bug or feature request. This helps reduce duplicate issues and the amount of time we spend triaging, and helps you get an answer more quickly.


We believe in open development. Our roadmap is public so that you can plan your development efforts accordingly. See our project boards on Github for details about our high level goals for each quarter. These usually consist of components we're building or other large projects.

For individual bugs or features, we use GitHub milestones and issue assignment to track upcoming releases. If an issue is assigned to a team member, then it is in progress. If it's been placed in a milestone, then you can expect it to be released in that version.


If you would like to help expedite a feature, there are a few ways to help. In prioritizing our work, the core team looks at community demand for a feature. Using the 👍 emoji reaction on issues helps us know how popular a request is. Please use it to indicate to us that you're interested in a feature.

The fastest way to get a feature implemented is to to contribute it yourself! Please read our contributing guide for more information. Please post a comment on the issue indicating that you'd like to work on it. A core team member will reach out to discuss how we'd like to go about it. This helps avoid rework in the PR review process.

Release schedule#

We generally plan to release every 2-3 weeks. However, priority bug fixes may be released more quickly. Check out the Versioning docs to learn more about how we version and release React Spectrum.


We release new components and features we're working on in stages before their stable release so that the community can help test them out. Our pre-releases include nightlies, alpha, beta and rc. Below we describe what each stage means, and the testing, docs, and API stability you can expect.


Nightly versions are published automatically, and include all code that has been merged that day. Nightlies can be used to access changes before they are published as alphas, however they have not been tested beyond the level done for individual pull requests.


Alpha packages are the first official version available. This means that the API has not been vetted beyond initial conception and implementation. Alpha packages may or may not have documentation, however they have had a basic level of testing across a number of different devices. Alpha packages are considered unstable and individual changes will not be documented in release notes.


Beta packages are considerably more stable than alphas. API changes may still occur in beta versions, however once in beta, this is less likely to happen. There may be outstanding features or issues in beta versions, which will be reported on GitHub. Initial documentation will also be available, and accessibility and design audits are conducted as part of this version.


RC is the last stage before release. The API is very unlikely to change, and all known issues have been addressed. More complete documentation and translations are also available for RC packages.


This is a stable version. All documentation, accessibility, and design reviews are finalized, and no breaking changes are allowed.