Update release policy page#688
Conversation
There was a problem hiding this comment.
The bootstrapping is always difficult. Given that, why don't we give an explicit example like 2026 and 2027 release plan, @HyukjinKwon and @cloud-fan ?
For example, I guessed like the following but it seems that this PR has a different timeline.
- 4.2.0 (The original plan): 2026 Summer + 18 months.
- 4.3.0 (LTS based on SPIP)
- 4.3.0 RC1 will start after 3 months from the release day of Apache Spark 4.2.0 in 2026.
- In 2027, Spark 5 will start as the annual release with the quarterly feature releases.
- Spark 5.0: 2027.1
- Spark 5.1: 2027.4
- Spark 5.2: 2027.7
- Spark 5.3: 2027.10 (LTS based on SPIP)
I just want to understand our plan of migration toward this SPIP. So, if there is an explicit example for 2026 and 2027. It would be perfect for me and all. The above is only one of personal understanding.
|
cc @peter-toth , too. |
|
I believe this is ready for another look. |
| Each feature release will have a merge window where new patches can be merged, a QA window when | ||
| <li><strong>MAJOR</strong>: Major releases occur annually (every 12 months) as <strong>x.0.0</strong> releases. These releases may | ||
| include <strong>breaking changes</strong>, third-party dependency upgrades, and other changes that are not | ||
| compatible within the same major line. Within a major line, all <strong>x.y.z</strong> releases share API compatibility |
There was a problem hiding this comment.
shoud be: other changes not compatible with the PREVIOUS major line?
| Each feature release will have a merge window where new patches can be merged, a QA window when | ||
| <li><strong>MAJOR</strong>: Major releases occur annually (every 12 months) as <strong>x.0.0</strong> releases. These releases may | ||
| include <strong>breaking changes</strong>, third-party dependency upgrades, and other changes that are not | ||
| compatible within the same major line. Within a major line, all <strong>x.y.z</strong> releases share API compatibility |
There was a problem hiding this comment.
do you actually mean: other changes that are not compatible with the PREVIOUS major line?
| compatible within the same major line. Within a major line, all <strong>x.y.z</strong> releases share API compatibility | ||
| as described in the <strong>FEATURE</strong> and <strong>MAINTENANCE</strong> bullets below.</li> | ||
| <li><strong>FEATURE</strong>: Feature releases occur quarterly (every 3 months) and contain new features, performance | ||
| improvements, API additions, and bug fixes. To ensure safe and predictable upgrades for downstream |
There was a problem hiding this comment.
how about API deletion/deprecation? shall we mention in the Major block?
| <li>No third-party dependency upgrades (e.g. Parquet, Arrow, ORC, Hadoop, Netty) by default. Upgrades | ||
| required to address <strong>security</strong> issues may be allowed; any other exception is decided case by case by | ||
| the release managers and the community.</li> | ||
| <li>No behavior or semantic changes (e.g. SQL semantics, execution behavior, optimizer behavior, |
There was a problem hiding this comment.
what optimizer behavior mean here? does optimizer change that brings perf improvement count for behavior change?
| include <strong>breaking changes</strong>, third-party dependency upgrades, and other changes that are not | ||
| compatible within the same major line. Within a major line, all <strong>x.y.z</strong> releases share API compatibility | ||
| as described in the <strong>FEATURE</strong> and <strong>MAINTENANCE</strong> bullets below.</li> | ||
| <li><strong>FEATURE</strong>: Feature releases occur quarterly (every 3 months) and contain new features, performance |
There was a problem hiding this comment.
to be consistent with the other two blocks, add version format like: Maintenance releases (x.y.z with z ≥ 1)
| <p>The branch is cut every January and July, so feature (“minor”) releases occur about every 6 months in general. | ||
| Hence, Spark 2.3.0 would generally be released about 6 months after 2.2.0. Maintenance releases happen as needed | ||
| in between feature releases. Major releases do not happen according to a fixed schedule.</p> | ||
| <p>Starting with Spark 4.3, feature releases occur quarterly (every 3 months), containing new features, |
There was a problem hiding this comment.
4.2, or 4.3? because starting 4.2, in 3 months there will be 4.3.
| Hence, Spark 2.3.0 would generally be released about 6 months after 2.2.0. Maintenance releases happen as needed | ||
| in between feature releases. Major releases do not happen according to a fixed schedule.</p> | ||
| <p>Starting with Spark 4.3, feature releases occur quarterly (every 3 months), containing new features, | ||
| improvements, and bug fixes. Major releases occur annually (every 12 months), allowing breaking |
There was a problem hiding this comment.
for Major release, given it's anually, do you want to propose a window in a year, like May-ish, Sep-ish, etc?
| 6 months (see the <strong>Major</strong> and <strong>Feature</strong> rows in the table above).</p> | ||
|
|
||
| <p>Under the quarterly cadence, the <strong>third</strong> feature release after each major—<strong>x.3.0</strong>—is designated | ||
| as the LTS (Long-Term Support) release for that major line and is maintained for <strong>18 months</strong> (for example |
There was a problem hiding this comment.
instead of saying the 3rd release, is it safer to say the last feature release within a major line is the LTS, so that there are more flexibilities?
6 participants
This PR updates Release Policy page per SPIP: Accelerating Apache Spark Release Cadence.