+1 for 4 months. With QA taking about a month, that's very reasonable. My main ask (especially for MLlib) is for contributors and committers to take extra care not to delay on updating the Programming Guide for new APIs. Documentation debt often collects and has to be paid off during QA, and a longer cycle will exacerbate this problem.
On Wed, Sep 28, 2016 at 7:30 AM, Tom Graves <tgraves...@yahoo.com.invalid> wrote: > +1 to 4 months. > > Tom > > > On Tuesday, September 27, 2016 2:07 PM, Reynold Xin <r...@databricks.com> > wrote: > > > We are 2 months past releasing Spark 2.0.0, an important milestone for the > project. Spark 2.0.0 deviated (took 6 month from the regular release > cadence we had for the 1.x line, and we never explicitly discussed what the > release cadence should look like for 2.x. Thus this email. > > During Spark 1.x, roughly every three months we make a new 1.x feature > release (e.g. 1.5.0 comes out three months after 1.4.0). Development > happened primarily in the first two months, and then a release branch was > cut at the end of month 2, and the last month was reserved for QA and > release preparation. > > During 2.0.0 development, I really enjoyed the longer release cycle > because there was a lot of major changes happening and the longer time was > critical for thinking through architectural changes as well as API design. > While I don't expect the same degree of drastic changes in a 2.x feature > release, I do think it'd make sense to increase the length of release cycle > so we can make better designs. > > My strawman proposal is to maintain a regular release cadence, as we did > in Spark 1.x, and increase the cycle from 3 months to 4 months. This > effectively gives us ~50% more time to develop (in reality it'd be slightly > less than 50% since longer dev time also means longer QA time). As for > maintenance releases, I think those should still be cut on-demand, similar > to Spark 1.x, but more aggressively. > > To put this into perspective, 4-month cycle means we will release Spark > 2.1.0 at the end of Nov or early Dec (and branch cut / code freeze at the > end of Oct). > > I am curious what others think. > > > > >
