While the point about being less time is probably correct, yeah if
something is half-done, we should keep them in the master branch, and/or
don't expose it to the end users (which I believe we usually do).
Good thing is that we can make the schedule predictable. Suppose that the
branchcut date is p
I don't think there is a delay per se, because there is no hard release
date to begin with, to delay with respect to. It's been driven by, "feels
like enough stuff has gone in" and "someone is willing to roll a release",
and that happens more like every 8-9 months. This would be a shift not only
in
Hi,
Sorry for a silly question, but do we know what exactly caused these
delays? Are these avoidable?
It is not a systematic observation, but my general impression is that we
rarely delay for sake of individual features, unless there is some soft
consensus about their importance. Arguably, t
+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
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 p
