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 which bump up session from x.y.z => x.y.z+1, every month or so (could be bit longer in near term 2020, until we build out a robust release qualification infra structure)

We will always be releasing from master and thus major release features need to be guarded by flags, on minor versions.
- We will try to avoid patch releases. i.e cherry-picking a few commits onto an earlier release version. (du. . ing 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.y to x.y+1. The idea here is this ships once all the committed features are code complete, tested and verified. -.

- ~ 
- We keep doing patches, bug fixes and usability improvements to the project always. So, we will also do a "time driven" minor version release x.y.z → x.y.z+1 every month or so 
- 

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)

,