Re: 10.0

​Tom brought up my own thoughts on the rest - but, really, this is a cynical way of looking at things.  At least insofar as whether marketing has say over what exact version number is assigned to a release should, and here likely does, have almost zero influence on the quality of the code that went into said release.  This entire discussion and timeline is proof of exactly that.  We have the option to market version 10.0.0 if we so choose but during the entire past year -core hasn't cared whether the release they are working toward is eventually numbered 9.6.0 or 10.0.0​ - and I posit that nothing would have changed had it been decided a year ago that we were going to release 10.0.0.

I'll accept that addressing the broader community's confusion regarding our version numbering scheme is a problem worth addressing.  Therefore I support moving to a simple "version.patch" system for next year's release.  Having accepted the importance of accepting the broader community's opinions changing to 10 now after we've released beta1 would be counter-productive.

Personally, having come in around the 8.2 release I didn't, and quite honestly still don't, care why the decision was made to release 9.0 instead of 8.5.  Mainly because the feature oriented decisions to increment seems to be largely focused on the DBA - which is it not my primary concern.  For me, the inclusion of window functions would have been enough to warrant a major version bump - and CTEs as well.  Both of those went into 8.4.  So not only is it getting harder to gain critical mass in a single release (which is good - it means we are not settling for the easy stuff and are properly breaking down harder features into small releaseables) but the stuff we are keying on are likely of secondary importance to a large number of users. 

David J.