. 

This page describes our release principles, methodology and also the actual process followed. 

Minor releases

We are constantly accepting contributions to fix bugs or improve usability or improving code quality. We strive to do "time driven" minor releases that move the version from x.y.z to x.y.z+1. Our North Star is it to be able to do so every month or so. This requires an extremely robust release qualification infrastructure which we are currently investing into. Until that’s in place, the timeline can be bit longer than that.

 We will try to avoid patch releases. i.e cherry-picking a few commits onto an earlier release version. (during 0.5.3 we actually found the cherry-picking of master onto 0.5.2 pretty tricky and even error-prone).  Some cases, we may have to just make patch releases. But only extenuating circumstances. Over time, with better tooling and a larger community, we might be able to do this. 

Major releases

Major releases are "feature driven" and we aim to do them every 3 months or so. We go. from version x.yto x.y+1. The idea here is this ships once all the committed features are code complete, tested and verified. Since we ship code from master and major features can be landing all the time, as we make minor releases, its imperative that any large features have enough flags and sensible defaults to not be disruptive. 

As for the major release planning process.

• PMC/Committers can come up with an initial list sourced based on user asks, support issue
• List is shared with the community, for feedback. community can suggest new items, re-prioritizations
• Contributors are welcome to commit more features/asks, (with due process)

,