Hi Holden, Mridul, Huaxin, and John. Thank you for sharing the idea — I appreciate the initiative and the thought behind it.
That said, the proposal feels a bit fragile to me without a clearer delivery and maintenance plan. To help us better evaluate and align on this, could you share a more concrete plan for how the proposal would be maintained and delivered, specifically for branch-3.5 during the extended period? (if you want to move forward with branch-3.5). In particular, it would be very helpful to understand the following technical and operational aspects: a. What is the exact duration of the proposed extension for branch-3.5? Currently, Apache Spark website says "For example, 3.5.0 was released on September 13th 2023 and will be maintained for 31 months until April 12th 2026." b. Who would be serving the community as release managers during that period? I assume Holden, Mridul, and Huaxin would be willing to volunteer for those roles, at least for the duration of the extension. c. Beyond the release manager responsibilities, would you also be planning to act as first responders during the extended period? - For monitoring, maintaining and recovering the release scripts and CI for branch-3.5 - For reviewing community security-related PRs targeting branch-3.5 - For responding to requests from the ASF Security Team on the dev@spark mailing list regarding branch-3.5 Thanks in advance for the clarification. I think having more detail here will really help the community assess the burden of proposal and move the discussion forward constructively. Best regards, Dongjoon On 2026/01/09 03:30:01 Holden Karau wrote: > in-line: > > On Thu, Jan 8, 2026 at 6:04 PM John Zhuge <[email protected]> wrote: > > > +1, I think this is a good idea. > > > > > > On Thu, Jan 8, 2026 at 4:52 PM Dongjoon Hyun <[email protected]> wrote: > > > >> Hi, Holden. > >> > >> Are you proposing to extend all future LTSs or just 3.5.x LTS? > >> > > I'm focused on 3.5 for now, I think we'll find out if our new > frequent release cadence makes upgrades easier for people. > > > > >> When we have a major release and its LTS every year from 2027, could you > >> give us next 3 year examples of your future release plans based on the > >> existing "SPIP: Accelerating Apache Spark Release Cadence" policy and your > >> new proposal together? > > > > I'm not yet saying that I think we should add a security-only period to > the end of all future major releases, although it is a very natural > extension of my suggestion so thanks for asking :) > > Personally I think we'll see what the upgrade cycle and support cycle looks > like with the new SPIP and depending on how 3.5 security only fixes and how > the yearly LTS releases go we can evaluate something further down the line. > I could see us adding a security updates only period to the LTS releases > though but I do want to do a trial with 3.5 where we've already got vendors > committed to supporting it (albiet commercially). > > > > >> Dongjoon. > >> > >> On 2026/01/09 00:17:45 huaxin gao wrote: > >> > +1 for extending LTS with security-only fixes for an additional 24 > >> months. > >> > > >> > On Thu, Jan 8, 2026 at 3:28 PM Mridul Muralidharan <[email protected]> > >> wrote: > >> > > >> > > > >> > > +1 for security fixes. > >> > > > >> > > Regards, > >> > > Mridul > >> > > > >> > > On Thu, Jan 8, 2026 at 3:52 PM Holden Karau <[email protected]> > >> > > wrote: > >> > > > >> > >> Hi Folks, > >> > >> > >> > >> I'd like to float the idea of extending our LTS release support > >> period > >> > >> for security fixes. In practice we've seen most vendors support the > >> LTS > >> > >> releases long past the official OSS support window. This went on for > >> a > >> > >> super long time with 2.4, and even in 3.5 we see much longer vendor > >> LTS > >> > >> periods support of 3.5 in Databricks dropping in 2028, Amazon in > >> 2027, > >> > >> etc. If 2.4 is any indication, these might slip out even longer. > >> > >> > >> > >> If we did security-only fixes for an additional 24 months after the > >> end > >> > >> of bug-fix period, it would let us poll our resources for security > >> > >> maintenance. > >> > >> > >> > >> Cheers, > >> > >> > >> > >> Holden > >> > >> > >> > >> -- > >> > >> Twitter: https://twitter.com/holdenkarau > >> > >> Fight Health Insurance: https://www.fighthealthinsurance.com/ > >> > >> <https://www.fighthealthinsurance.com/?q=hk_email> > >> > >> Books (Learning Spark, High Performance Spark, etc.): > >> > >> https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9> > >> > >> YouTube Live Streams: https://www.youtube.com/user/holdenkarau > >> > >> Pronouns: she/her > >> > >> > >> > > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe e-mail: [email protected] > >> > >> > > > > -- > > John Zhuge > > > > > -- > Twitter: https://twitter.com/holdenkarau > Fight Health Insurance: https://www.fighthealthinsurance.com/ > <https://www.fighthealthinsurance.com/?q=hk_email> > Books (Learning Spark, High Performance Spark, etc.): > https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9> > YouTube Live Streams: https://www.youtube.com/user/holdenkarau > Pronouns: she/her > --------------------------------------------------------------------- To unsubscribe e-mail: [email protected]
