Regarding documentation debt, is there a reason not to deploy documentation updates more frequently than releases? I recall this used to be the case.
On Wed, Sep 28, 2016 at 3:35 PM, Joseph Bradley <jos...@databricks.com> wrote: > +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. >> >> >> >> > --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
