According to the SPIP doc, seems we are going to keep the new features in minor versions:
- Improvements and new features only in minor releases (no change here). - *Dependencies are frozen* and behavioral changes are minimized in minor releases. In order to do so, especially now as we have cut 4.x branch, does that mean new feature PRs should target both master and 4.x branch? With the current CI setup, for each improvement and feature PR, besides targeting master, I think we will have to manually create an additional backport PR targeting the 4.x branch. Is my understanding correct? To make this process easier, we could set up a mechanism to do pre-merge CI on the backport branch as well, in the same PR, then use a bot to backport the commit onto the additional target branch (e.g., 4.x). But then questions become 1) do we have the resources to run additional pre-merge CI? 2) can we use that kind of bot to push to a branch (it may change the committer to bot)? Would love to know what's the best way to merge future PRs ;) Best, Yicong Huang <https://yicong-huang.github.io> On Dec 8, 2025 at 3:55 PM -0800, Anish Shrigondekar via dev < [email protected]>, wrote: +1 One question I had though was how we think of long-running larger features developed in open-source ? If we merge them to master, are we ok to keep the APIs/features as experimental/hidden before we are ready for release ? Also - are we allowed to change these APIs across minor releases and do we need to wait for the next major release to make them available publicly? Thanks, Anish On Mon, Dec 8, 2025 at 3:50 PM DB Tsai <[email protected]> wrote: > +1 > > DB Tsai | https://www.dbtsai.com/ > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dbtsai.com%2F&data=05%7C02%7Cyiconghuang%40umass.edu%7C04ba893177ad4cc2845f08de36b55083%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639008349539882104%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=utGD8G7ixcj3DVrRuq4hslghxIVZyY44b9Z48U%2B0%2FFk%3D&reserved=0> > | PGP 42E5B25A8F7A82C1 > > On Dec 8, 2025, at 2:18 PM, Gengliang Wang <[email protected]> wrote: > > +1 for faster and predictable release. > > On Sun, Dec 7, 2025 at 1:58 PM Hyukjin Kwon <[email protected]> wrote: > >> PS: I would like to stop preview releases once this SPIP passes as we >> will have relatively quick releases. However, I plan to start another vote >> separately to avoid mixing this proposal with stopping previews. >> >> On Mon, 8 Dec 2025 at 06:52, Hyukjin Kwon <[email protected]> wrote: >> >>> Hi all, >>> >>> I would like to start a discussion on accelerating the Apache Spark >>> release cadence. Over the past four months, we have been running preview >>> releases, and the process has been smooth and effective. As mentioned in >>> the preview release discussion thread, I’d now like to extend this approach >>> to official releases. >>> >>> During this period, I also looked into how other large projects, such as >>> Kubernetes and Python, manage their release timelines. Based on that >>> research and our own recent experience, I’ve drafted a proposal for an >>> updated Apache Spark release plan. >>> >>> TL;DR: >>> >>> - Introduce a predictable release schedule: annual major releases >>> and quarterly minor releases, so users can benefit from new features >>> earlier. >>> - With a faster cadence for minor releases, we should take a more >>> conservative approach toward behavior changes in minor versions, while >>> still allowing new features and improvements. >>> >>> I’d love to hear your thoughts and feedback. >>> >>> More details can be found in SPIP: Accelerating Apache Spark Release >>> Cadence >>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1gBoZ4KH5zQUWpgK3M7zAN7p6Glz4S_e9bO3PvQA9sQs%2Fedit%3Fusp%3Dsharing&data=05%7C02%7Cyiconghuang%40umass.edu%7C04ba893177ad4cc2845f08de36b55083%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639008349539897458%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cQwxKyDHcbTPtru6PU3Nl4LtX4ZgYzjj7bdvB70rmaQ%3D&reserved=0> >>> >>> Thanks! >>> >> > Best regards, Yicong Huang
