dongjoon-hyun commented on code in PR #688: URL: https://github.com/apache/spark-website/pull/688#discussion_r3239114538
########## site/versioning-policy.html: ########## @@ -164,19 +164,31 @@ <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, third-party dependency +upgrades, and major code refactoring. All releases with the same major version number will have +API compatibility.</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).</li> + <li>No behavior or semantic changes (e.g. SQL semantics, execution behavior, optimizer behavior, +configuration defaults). Exceptions might occur case by case (e.g., security issues).</li> + <li>Public APIs may be added but not changed or removed.</li> + </ul> + </li> +</ul> + +<p>Each feature release will have a merge window where new patches can be merged, a QA window when only fixes can be merged, then a final period where voting occurs on release candidates. These windows will be announced immediately after the previous feature release to give people plenty -of time, and over time, we might make the whole release process more regular (similar to Ubuntu).</li> - <li><strong>MAINTENANCE</strong>: Maintenance releases will occur more frequently and depend on specific patches -introduced (e.g. bug fixes) and their urgency. In general these releases are designed to patch bugs. -However, higher level libraries may introduce small features, such as a new algorithm, provided -they are entirely additive and isolated from existing code paths. Spark core may not introduce -any features.</li> +of time.</p> +<ul> + <li><strong>MAINTENANCE</strong>: Maintenance releases will occur on an ad hoc basis depending on specific patches +introduced (e.g. critical bug fixes and security patches) and their urgency. In general these releases +are designed to patch bugs. However, higher level libraries may introduce small features, such as a Review Comment: - First, what is the definition of `higher level libraries`? In the context, this could mean every module except `Spark Core`. In other words, `SQL`, `MLLIB`, `GRAPHX` and so on. - Second, why do we need to allow this in the maintenance releases? I believe we had better keep the policy simple. In other words, no new features at all. > However, higher level libraries may introduce small features, such as a new algorithm, provided they are entirely additive and isolated from existing code paths. -- 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]
