+1 for Hyukjin and Sean's opinion. Thank you for initiating this discussion.
If we have a fixed-predefined regular 6-month, I believe we can persuade the incomplete features to wait for next releases more easily. In addition, I want to add the first RC1 date requirement because RC1 always did a great job for us. I guess `branch-cut + 1M (no later than 1month)` could be the reasonable deadline. Thanks, Dongjoon. On Tue, Feb 14, 2023 at 6:33 AM Sean Owen <sro...@gmail.com> wrote: > 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? >> >
