jingyimei commented on code in PR #688: URL: https://github.com/apache/spark-website/pull/688#discussion_r3263089252
########## site/versioning-policy.html: ########## @@ -164,19 +164,32 @@ <h3>Spark versions</h3> <p>Each Spark release will be versioned: <code class="language-plaintext highlighter-rouge">[MAJOR].[FEATURE].[MAINTENANCE]</code></p> <ul> - <li><strong>MAJOR</strong>: All releases with the same major version number will have API compatibility. -Major version numbers will remain stable over long periods of time. For instance, 1.X.Y may last -1 year or more.</li> - <li><strong>FEATURE</strong>: Feature releases will typically contain new features, improvements, and bug fixes. -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 Review Comment: shoud be: other changes not compatible with the PREVIOUS major line? ########## site/versioning-policy.html: ########## @@ -164,19 +164,32 @@ <h3>Spark versions</h3> <p>Each Spark release will be versioned: <code class="language-plaintext highlighter-rouge">[MAJOR].[FEATURE].[MAINTENANCE]</code></p> <ul> - <li><strong>MAJOR</strong>: All releases with the same major version number will have API compatibility. -Major version numbers will remain stable over long periods of time. For instance, 1.X.Y may last -1 year or more.</li> - <li><strong>FEATURE</strong>: Feature releases will typically contain new features, improvements, and bug fixes. -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 +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 +projects, feature releases have the following compatibility: + <ul> + <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, Review Comment: what optimizer behavior mean here? does optimizer change that brings perf improvement count for behavior change? ########## site/versioning-policy.html: ########## @@ -164,19 +164,32 @@ <h3>Spark versions</h3> <p>Each Spark release will be versioned: <code class="language-plaintext highlighter-rouge">[MAJOR].[FEATURE].[MAINTENANCE]</code></p> <ul> - <li><strong>MAJOR</strong>: All releases with the same major version number will have API compatibility. -Major version numbers will remain stable over long periods of time. For instance, 1.X.Y may last -1 year or more.</li> - <li><strong>FEATURE</strong>: Feature releases will typically contain new features, improvements, and bug fixes. -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 +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 Review Comment: to be consistent with the other two blocks, add version format like: Maintenance releases (<strong>x.y.z</strong> with <strong>z ≥ 1</strong>) ########## site/versioning-policy.html: ########## @@ -274,9 +287,10 @@ <h4>Alternatives to breaking an API</h4> <h2>Release cadence</h2> -<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, +improvements, and bug fixes. Major releases occur annually (every 12 months), allowing breaking Review Comment: for Major release, given it's anually, do you want to propose a window in a year, like May-ish, Sep-ish, etc? ########## site/versioning-policy.html: ########## @@ -164,19 +164,32 @@ <h3>Spark versions</h3> <p>Each Spark release will be versioned: <code class="language-plaintext highlighter-rouge">[MAJOR].[FEATURE].[MAINTENANCE]</code></p> <ul> - <li><strong>MAJOR</strong>: All releases with the same major version number will have API compatibility. -Major version numbers will remain stable over long periods of time. For instance, 1.X.Y may last -1 year or more.</li> - <li><strong>FEATURE</strong>: Feature releases will typically contain new features, improvements, and bug fixes. -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 +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 Review Comment: how about API deletion/deprecation? shall we mention in the Major block? ########## site/versioning-policy.html: ########## @@ -274,9 +287,10 @@ <h4>Alternatives to breaking an API</h4> <h2>Release cadence</h2> -<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, Review Comment: 4.2, or 4.3? because starting 4.2, in 3 months there will be 4.3. ########## site/versioning-policy.html: ########## @@ -303,16 +317,78 @@ <h3>Spark 4.2 release window</h3> </tbody> </table> +<h3>Illustrative transition: 2026 and 2027</h3> + +<p>The calendar below is an <strong>example</strong> to show how the community expects to bootstrap the faster cadence; +exact dates stay subject to the usual release-discussion and voting process.</p> + +<ul> + <li><strong>2026</strong>: Ship <strong>Apache Spark 4.2.0</strong> on the timeline above (the last <em>large</em> feature drop before the +transition). Treat <strong>4.2.x</strong> like other non-LTS branches (6 month maintenance window). After <strong>4.2.0</strong> +is generally available, plan <strong>Apache Spark 4.3.0</strong> as the first quarterly feature release on the new +train (for example, roughly <strong>three months</strong> after the <strong>4.2.0</strong> GA date for the start of the <strong>4.3</strong> merge/RC +cycle—this is not a fixed rule, only an illustration of quarterly feature releases).</li> + <li><strong>2027</strong>: Ship <strong>Apache Spark 5.0.0</strong> as the next <strong>annual</strong> major. Follow with quarterly <strong>5.1.0</strong>, +<strong>5.2.0</strong>, and <strong>5.3.0</strong> feature releases; <strong>5.3.0</strong> is the <strong>5.x</strong> LTS per the <strong>x.3.0</strong> rule above +(for example targeting calendar quarters <strong>2027 Q1</strong> through <strong>Q4</strong> if the <strong>5.0.0</strong> major lands early +in the year).</li> +</ul> + <h2>Maintenance releases and EOL</h2> -<p>Feature release branches will, generally, be maintained with bug fix releases for a period of 18 months. -For example, branch 2.3.x is no longer considered maintained as of September 2019, 18 months after the release -of 2.3.0 in February 2018. No more 2.3.x releases should be expected after that point, even for bug fixes.</p> +<p>The following table summarizes the maintenance window for each release type:</p> + +<table> + <thead> + <tr> + <th>Release Type</th> + <th>Cadence</th> + <th>Maintenance Window</th> + </tr> + </thead> + <tbody> + <tr> + <td>Major (x.0.0)</td> + <td>Annually</td> + <td>6 months</td> + </tr> + <tr> + <td>Feature (x.[1–2].0)</td> + <td>Every 3 months</td> + <td>6 months</td> + </tr> + <tr> + <td>LTS (x.3.0)</td> + <td>Every 3 months (last feature of the major line)</td> + <td>18 months</td> + </tr> + <tr> + <td>Maintenance (x.y.z, z ≥ 1)</td> + <td>Ad hoc</td> + <td>N/A (patches only)</td> + </tr> + </tbody> +</table> + +<p>Release branches <strong>other than LTS</strong> will, generally, be maintained with bug fix releases for a period of +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 Review 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? ########## site/versioning-policy.html: ########## @@ -164,19 +164,32 @@ <h3>Spark versions</h3> <p>Each Spark release will be versioned: <code class="language-plaintext highlighter-rouge">[MAJOR].[FEATURE].[MAINTENANCE]</code></p> <ul> - <li><strong>MAJOR</strong>: All releases with the same major version number will have API compatibility. -Major version numbers will remain stable over long periods of time. For instance, 1.X.Y may last -1 year or more.</li> - <li><strong>FEATURE</strong>: Feature releases will typically contain new features, improvements, and bug fixes. -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 Review Comment: do you actually mean: other changes that are not compatible with the PREVIOUS major line? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
