I'm fine with shifting to a stricter cadence-based schedule. Sometimes, it'll mean some significant change misses a release rather than delays it. If people are OK with that discipline, sure. A hard 6-month cycle would mean the minor releases are more frequent and have less change in them. That's probably OK. We could also decide to choose a longer cadence like 9 months, but I don't know if that's better. I assume maintenance releases would still be as-needed, and major releases would also work differently - probably no 4.0 until next year at the earliest.
On Tue, Feb 14, 2023 at 3:01 AM Hyukjin Kwon <gurwls...@gmail.com> wrote: > Hi all, > > *TL;DR*: Branch cut for every 6 months (January and July). > > I would like to discuss/propose to make our release cadence predictable. > In our documentation, we mention as follows: > > In general, feature (“minor”) releases occur about every 6 months. Hence, > Spark 2.3.0 would generally be released about 6 months after 2.2.0. > > However, the reality is slightly different. Here is the time it took for > the recent releases: > > - Spark 3.3.0 took 8 months > - Spark 3.2.0 took 7 months > - Spark 3.1 took 9 months > > Here are problems caused by such delay: > > - The whole related schedules are affected in all downstream projects, > vendors, etc. > - It makes the release date unpredictable to the end users. > - Developers as well as the release managers have to rush because of > the delay, which prevents us from focusing on having a proper > regression-free release. > > My proposal is to branch cut every 6 months (January and July that avoids > the public holidays / vacation period in general) so the release can happen > twice > every year regardless of the actual release date. > I believe it both makes the release cadence predictable, and relaxes the > burden about making releases. > > WDYT? >
