You are absolutely right, Baloo - more frequent updates would be great. I'll give some more perspective on it:

- One approach is to make "major-feature-updates" (X), "minor-feature-updates"(Y) and "feature updates"(Z) - X.Y.Z. This is the way you see Operating Systems or large software suites released. That's what we did with Dolphin and to some extent with UNA. The downside is that you need to create separate branches for service and feature updates, and then merge-in all service updates into the feature-update branch before release. That adds a couple of days to each packaging procedure and also complicates development, issue tracking and time estimations. 

- Another approach is to release frequent regular combo-updates (features+fixes) and, only when necessary, urgent security patches (which get merged into the main development branch straight away). This approach is becoming more common (made popular by Chrome team) as it allows for faster evolution and reduces organisational overhead. As a result, you get versions like 9-10-11-....-67.. very quickly.   

With current resources, we are in favour of the combo-updates route. Ideally, we'd like to release at least once a month, with both fixes and feature-updates, and also decouple it from apps-updates wherever possible (apps updates can be pushed separately, as long as they're not dependent on associated core platform updates). That's the plan, but not everything goes according to the plan...

This upcoming update (RC10) is unusually big - it follows two rushed feature updates and includes a lot of fixes, it also required significant code overhaul for Mission: Notifications and also a few core updates to accommodate #Labels and #Channels. Moreover, we're going through all pages to clean up UX inconsistencies and run tests on multiple platforms and browsers via BrowserStack. 

All in all - very testing times for us, as we're facing the storm of development backlog, clients requests (which is crucial for the bottom line) and the urgent need to improve deployment (Cloud) orchestration, failover, etc. 

Sometimes I think we'd be in much better position if we did go for external funding and on-boarded more staff, but that would also mean less freedom of choice and more pressure to focus on revenue. As product-people, we rather hope to be able to build an amazing platform and let that solve everything. Keeping fingers crossed and commits coming in. :)