In theory releases happen on a time-based cadence, so it's pretty much wrap up what's ready by the code freeze and ship it. In practice, the cadence slips frequently, and it's very much a negotiation about what features should push the code freeze out a few weeks every time. So, kind of a hybrid approach here that works OK.
Certainly speak up if you think there's something that really needs to get into 2.4. This is that discuss thread. (BTW I updated the page you mention just yesterday, to reflect the plan suggested in this thread.) On Mon, Jul 30, 2018 at 9:51 AM Tom Graves <tgraves...@yahoo.com.invalid> wrote: > Shouldn't this be a discuss thread? > > I'm also happy to see more release managers and agree the time is getting > close, but we should see what features are in progress and see how close > things are and propose a date based on that. Cutting a branch to soon just > creates more work for committers to push to more branches. > > http://spark.apache.org/versioning-policy.html mentioned the code freeze > and release branch cut mid-august. > > > Tom > >
