Skip to content

[SPARK-55489] Update extended LTS period post SPIP ratification #682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
holdenk wants to merge 9 commits into from
+6 −2
Closed

[SPARK-55489] Update extended LTS period post SPIP ratification #682

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
99282c0
Add a note about the 3.5 eLTS period.
holdenk Mar 16, 2026
c76f512
Clarify the seperate sub projects.
holdenk Mar 16, 2026
5cccaf1
Regenerate the site
holdenk Mar 17, 2026
8a8a3a6
Update the note for versioning policy to not mention 4.0 in the conte…
holdenk Mar 23, 2026
ed9804c
Drop the 4.0 ref per CR feedback.
holdenk Mar 23, 2026
4a1630b
Fix extra space
holdenk Mar 23, 2026
0921280
Rebuild dropping space
holdenk Mar 23, 2026
725ac7b
Update the note to say we may decide won't fix too as a possibility.
holdenk Mar 24, 2026
b8ffeb3
Update versioning policy HTML.
holdenk Mar 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion site/versioning-policy.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -310,7 +310,9 @@ <h2>Maintenance releases and EOL</h2>
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 last minor release within a major release will typically be maintained for longer as an &#8220;LTS&#8221; release.
For example, 3.5.0 was released on September 13th 2023 and will be maintained for 31 months until April 12th 2026.</p>
For example, 3.5.0 was released on September 13th 2023 and would normally be maintained for 31 months until April 12th 2026.</p>

<p>As an exception from the normal versioning policy, version 3.5.x has an &#8220;extended&#8221; LTS period to allow for migrations to be completed. This extended LTS period will end <em>November 2027</em>. During the 3.5.x extended LTS period, we will only include security fixes. This extend LTS only applies to the primary Apache Spark project/repo and does not apply to sub projects with separate repos/releases (namely: Spark Connect for Swift/Rust/Go and Spark Kubernetes operator). Additionally, as Java 8 support is being removed from other projects (including Hadoop), should a dependency have a security fix that is not backported to a Java 8 compatible version we will drop Java 8 from the remainder of the extended LTS period.</p>

</div>
<div class="col-12 col-md-3">
Expand Down
5 changes: 4 additions & 1 deletion versioning-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,4 +115,7 @@ For example, branch 2.3.x is no longer considered maintained as of September 201
of 2.3.0 in February 2018. No more 2.3.x releases should be expected after that point, even for bug fixes.

The last minor release within a major release will typically be maintained for longer as an "LTS" release.
For example, 3.5.0 was released on September 13th 2023 and will be maintained for 31 months until April 12th 2026.
For example, 3.5.0 was released on September 13th 2023 and would normally be maintained for 31 months until April 12th 2026.


Comment thread
pan3793 marked this conversation as resolved.
Outdated
As an exception from the normal versioning policy, version 3.5.x has an "extended" LTS period to allow for migrations to be completed. This extended LTS period will end *November 2027*. During the 3.5.x extended LTS period, we will only include security fixes. This extend LTS only applies to the primary Apache Spark project/repo and does not apply to sub projects with separate repos/releases (namely: Spark Connect for Swift/Rust/Go and Spark Kubernetes operator). Additionally, as Java 8 support is being removed from other projects (including Hadoop), should a dependency have a security fix that is not backported to a Java 8 compatible version we will drop Java 8 from the remainder of the extended LTS period.
Copy link
Copy Markdown
Member

@pan3793 pan3793 Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@holdenk, thank you for updating this, but it seems that the Java 8 dropping clause appears to be a new language that goes beyond what the community voted on.

I think no community member proposed or discussed a mechanism for dropping Java 8 mid-LTS if a dependency's security fix isn't backported to a Java 8-compatible version. On the contrary, Steve Loughran expressed:

I think it's really good to have a stated security policy of maintenance,
and that you have the engineering resources to do the release -including
testing.

I think you ought to make clear to all downstream that even security fixes
are "best effort" and if compatibility issues surface you may not update a
transient dependency with known CVEs.

This is a real problem: what if there's an update to some library
"random-12.0" which needs to be upgraded to "random-13.1" to fix a CVE, but
that needs major code changes and could potentially break application code.
What to do? Issue a potentially incompatible release or say "can't fix".

https://lists.apache.org/thread/4r6q8187b30p0ppclw0pyfjp8h8xs3rq

which is more in line with reality.

Copy link
Copy Markdown
Contributor Author

@holdenk holdenk Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was based on my reply to Steves comment in SPIP doc which where i said "It runs on 8/11/17. I agree in the end user description we’ll make it clear if there’s CVE in a sub library that doesn’t backport the fix to a API compatible Java 8 version we won’t be able fix the Java 8 version. Hopefully this doesn’t come up in practice but we shall see." Which Steve gave a "thumbs up" react to. I think no one voting on this assumed we would and backport fixes in other libraries. Is there alternative language you'd prefer here?

Copy link
Copy Markdown
Contributor Author

@holdenk holdenk Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would "we may drop Java 8 or mark the issue as won't fix it" work for you? It doesn't commit us hard to one path or another.

Copy link
Copy Markdown
Member

@pan3793 pan3793 Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "drop Java 8" in 3.5.x likely won't happen, for cases that 3rd party libs official release does not provide a Java 8 compatible security patched version, what is more likely to happen is that someone maintains a security fork if the issue is really serious, e.g., log4j 1.x => reload4j.

But I'm okay with the current words, thank you, @holdenk

Copy link
Copy Markdown
Contributor Author

@holdenk holdenk Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huzzah

Loading