+1 -- I think the minor releases were taking more like 4 months than 3 months anyway, and it was good for the reasons you give. This reflects reality and is a good thing. All the better if we then can more comfortably really follow the timeline.
On Tue, Sep 27, 2016 at 3:06 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
