Release Process changes

[michael-s-molina]

During our last Operational Model: Release Strategy meeting, we discussed some changes to our Release Process. This discussion aims to highlight the proposed changes that will be submitted for lazy consensus.

The changes only affect the Schedule section of our Release Process. This is the original content:

Schedule

Superset releases will follow a time-based schedule to provide predictability and a regular cadence of updates. Keep in mind that we may delay or accelerate a release, or even alter its scope, due to special circumstances such as critical security fixes.

Major or Minor Version	State	First Release	EOL/Terminated
5.1	Planned	Dec 15, 2024	Jul 15, 2025
5.0	Planned	Sep 15, 2024	Mar 15, 2025
4.1	Planned	Jun 15, 2024	Dec 15, 2024
4.0	Planned	Mar 15, 2024	Sep 15, 2024
3.1	Supported	Dec 15, 2023	Jul 15, 2024
3.0	Supported	Sep 18, 2023	Mar 15, 2024
2.1	EOL	Aug 29, 2023	Dec 15, 2023
2.0	EOL	Jul 14, 2022	Apr 5, 2023
1.5	EOL	Apr 28, 2022	Apr 5, 2023
1.4	EOL	Jan 19, 2022	Apr 28, 2022

Apache Superset publishes the security vulnerabilities (CVEs) associated with each of its releases.

Due to resource constraints, we only support two versions (major or minor) at a time. This means that when a major or minor is released, we stop creating patches for a previous version. For example, if we are supporting 3.0 and 2.1 when 3.1 arrives, we'll drop support for 2.1 and only provide patches for 3.1 and 3.0. When 4.0 arrives, we'll drop support for 3.0 and so on.

The above statement does not prevent someone from the community from voluntarily creating a patch for an old release.

This is the proposed content after our discussion:

Schedule

Superset major releases will follow a time-based schedule to provide predictability and a regular cadence of updates. Keep in mind that we may delay or accelerate a release, or even alter its scope, due to special circumstances such as critical fixes. Minor and patch releases won't follow a specific schedule and can be made when necessary by community members.

Version	State	First Release	EOL/Terminated
9	Planned	Nov 15, 2026	Nov 15, 2027
8	Planned	May 15, 2026	May 15, 2027
7	Planned	Nov 15, 2025	Nov 15, 2026
6	Planned	May 15, 2025	May 15, 2026
5	Planned	Nov 15, 2024	Nov 15, 2025
4	Supported	Apr 8, 2024	May 15, 2025
3	Supported	Sep 18, 2023	Mar 15, 2024
2	EOL	Jul 14, 2022	Apr 5, 2023

Due to resource constraints, we only support two versions at a time, more specifically, the latest minor of the last two majors. This means that when a major is released, we stop creating patches for the oldest supported major version. For example, if we are supporting 2.x and 3.x when 4.x arrives, we'll drop support for 2.x and only provide patches for 3.x and 4.x. When 5.x arrives, we'll drop support for 3.x and so on. Another example is when 3.1 is released, we'll drop support for 3.0 because 3.1 is the latest minor.

Given the great code difference between major versions, we only support critical fixes for the oldest supported major version. We may also decide to not include a critical fix depending on the complexity of cherry-picking the fix. Users can always check the CHANGELOG.md file and the CVEs by release page to see if a particular fix is included in a release.

The above statements do not prevent someone from the community from voluntarily creating a patch for an unsupported release.

[michael-s-molina]

Lazy consensus reached.