---
id: app/references/roadmap
title: Roadmap for Cypress App
description: >-
  Learn about the roadmap for the Cypress App, including release stages and
  strategies for releasing and communicating changes.
section: app
source_path: docs/app/references/roadmap.mdx
version: ce02913654e2655ee63448bdc92bb92c7b46a619
updated_at: '2026-04-22T19:37:51.587Z'
---
# Roadmap

## Cypress App

At Cypress we love sharing what we are working on and are always striving to
improve transparency and communication with our community. If you are interested
in learning more about what we have planned for the future of the Cypress App
check out our
[Cypress App Priorities Board](https://github.com/orgs/cypress-io/projects/13/views/1).

## Release Stages

Cypress follows Semantic Versioning
([see summary here](https://semver.org/#summary)) so that it is clear how you
may be affected when upgrading to a newer version of Cypress. If there is a
minor version increment, `11.0.0` → `11.1.0` for example, you should not
experience disruption in your usage of Cypress. If there is a major version
increment, `11.1.0` → `12.0.0` for example, you may need to make changes to
continue using Cypress. For most scenarios this is a valid way to consider how
disruptive upgrading to the next version of Cypress may be. In some cases,
however, a feature of Cypress may be in a stage of development in which it does
not adhere to these rules.

In order to help our users be aware of when this might be the case, we have
consolidated definitions of the different release stages: General Availability,
Beta, Alpha, and Experimental. We also describe our approach to making and
communicating changes in each stage.

### General Availability (GA)

Features that have reached General Availability are features that we have deemed
to be feature complete and free of issues in the majority of use cases.

**Strategies for releasing and communicating changes to GA features**

- Modifications
  - Modifications can be introduced during any release cycle and increment
    semver
- Breaking Changes
  - Breaking changes will only be introduced during major releases in which
    semver is bumped by a major version
  - In some cases early access to these changes are possible through public
    packages
- Removals
  - Removals will only be introduced during major releases in which semver is
    bumped by a major version
  - In the majority of cases, removals will be proceeded by a period in which
    the feature is ‘deprecated’
  - Migration steps will be provided to minimize pain points in these situations

### Beta

Beta features may not be feature complete, but they should be close enough where
major changes are not expected. Beta features consist of features that we are
looking to gather user feedback on by providing them as default functionality
before an official release.

**Strategies for releasing and communicating changes to Beta features**

- Modifications
  - Modifications can be introduced during any release cycle.
  - Modifications will be documented, with recommended code changes highlighted
    if appropriate.
- Breaking Changes
  - Breaking changes can be introduced during any release cycle and do not bump
    semver by a major version
  - Breaking changes require in-app messaging to help users unblock themselves
    as needed
  - The introduction and impact of breaking changes should be carefully
    considered at this stage as the cost to users is higher than with an alpha
    feature.
- Removals
  - Removal of any new functionality related to the feature can happen during
    any release cycle and will increment semver. These do not need to coincide
    with a major release that is bumping semver by a major version.
  - Removals at this stage will be rare and a migration strategy along with
    reasoning for the removal will be documented.

### Alpha

Alpha features consist of features that we are looking to gather user feedback
on by providing them as default functionality before an official release. Alpha
features may not be feature complete and changes are possible during this stage.

**Strategies for releasing and communicating changes to Alpha features**

- Modifications
  - Modifications can be introduced during any release cycle and may or may not
    increment semver.
  - Modifications will be documented, with recommended code changes highlighted
    if appropriate.
- Breaking Changes
  - Breaking changes can be introduced during any release cycle and do not bump
    semver by a major version
- Removals
  - Removal of any new functionality related to the feature can happen during
    any release cycle and does not bump semver by a major version.

### Experimental

Experimental features consist of features that we are looking to gather user
feedback on before we commit fully to further development of the feature. These
type of features require you to opt-in to via a configuration value prefixed
with `experimental`. These types of features may be unstable and contain issues.
You should expect to see frequent changes and improvements during the feature’s
experimental lifetime. The current experimental features can be found
[here](/llm/markdown/app/references/experiments.md).

**Strategies for releasing and communicating changes to experimental features**

- Modifications
  - Modifications can be introduced during any release cycle and may or may not
    increment semver.
- Breaking Changes
  - Breaking changes can be introduced during any release cycle and do not bump
    semver by a major version.
- Removals
  - Removal of any new functionality related to the feature or the feature in
    its entirety can happen during any release cycle and will not be accompanied
    by a major semver version change.
