I too would like to see smaller “features” (though perhaps not features, just extra usability enhancements – extra SHOW STATUS variables, perhaps new variables that do not alter behavior by default but do when enabled, etc.) – as long as they are not considered destabilizing.

I’ve tried to do this myself (innodb_stats_on_metadata, innodb_adaptive_hash_index, logging access denied messages to the error log, FLUSH TIMEZONES, to name a few), and I feel your frustration. innodb_adaptive_hash_index made it in to 5.0 – but that was only because of Bug#20358.

We’re currently working from a single source tree for 5.1 GA is at least, and I’m part of a team within MySQL/Sun that is trying to make the project more contributor friendly with regards to these small additions – from both the community *and* internally, because Support and others, as I mentioned, also see the same frustration as you guys on the outside. Hopefully we all should start to see changes in this area in the new year.

There’s a lot of work going on to bring release timelines down as well, and maybe further interim releases on the table too (i.e between 5.1 and 6.0).

In hindsight, we should probably have called 5.1 “6.0″, and we should have allowed smaller features like SHOW PROFILE in to a 5.1 taken directly from the “current” 5.0 version, and other incremental new “smaller” features afterwards in to 5.2, 5.3, 5.4, 5.6, etc. as they came of age. This may happen from 5.1 now though.

I’m an advocate of differentiation *around* the server as well, for the record.

Stick with us guys, we *are* listening, and there’s a whole bunch of us trying to change things for the better, with the blessing of people all the way “at the top”.

I second the desire for one source tree. However, instead of plugins for Enterprise I would like to see the same features for both Community and Enterprise releases – the benefit of Enterprise being that you get support and the extra features like Query Analyzer and Enterprise Dashboard. I don’t understand any previously mentioned reasons to separate the releases into two trees – it only complicates the feature set and frustrates the users. There are community users that buy enterprise for certain servers and certain clients but do not forget that MySQL’s entire user base was built on the community – separating the features doesn’t do anyone any favors – even the paying customers.

MySQL should reduce the release time between major versions or add some (not major ones like RBR) features after the initial release of a version.

I expect that the Enterprise builds get additional features beyond what is in the one source tree as MySQL adds value via Enterprise only features, but I hope these are done via plugin interfaces.

That’s basically the only way this is ever going to work.. I know you didn’t advocate it, I’d like to know your opinion on what you would like to see with regards to new features in Community and Enterprise GA releases however (i.e when/where they should be pushed etc.)..

“Currently profiling is not available in any Enterprise release, not just missing from some.”

There *is* an Enterprise version available with profiling enabled – 5.1.30 GA – now it has been vetted by the community.. As was originally stated.. As was originally advocated by the author..

Confused? I am. Not because of the way we handled this, though..

“That means e.g. 5.0.45 has partitioning, while 5.0.70 does not.”

Oh I’m sure you didn’t mean partitioning there..

Arjen – doing an Enterprise build that is not based solely on the Enterprise source, is hardly doing an “Enterprise Build”, I’m not sure why you’d bother, rather than just sticking with the normal OurDelta builds with all of their enhancements anyway.. Not saying “don’t do it”, that’s of course up to you, but it certainly wouldn’t be “Enterprise” if you modify it, and you’re already modifying the other builds anyway..

“I can understand if that feature was something that wasn’t fully tested in the enterprise code base and thus was only released in the community version”

That’s *exactly* what happened, though. MySQL 5.0 went GA with 5.0.18. SHOW PROFILES and SHOW PROFILE were added in MySQL 5.0.37. The policy is to not add new features in to Enterprise GA releases (we were most certainly GA at 5.0.37), and only to include them in the *next* major GA release should they be acceptable.

Why oh why do people advocate this, and then complain in the one instance that we actually did this?

“Important

Please note that the SHOW PROFILE and SHOW PROFILES functionality is part of the MySQL 5.0 Community Server only.
”

[Admin note: this is OBVIOUS, and I've read the manual plenty of times - but that's not what this blog post is about in the first place.]

Here’s a great example: 5.0.68-enterprise does not have profiling. 5.0.67-community does have profiling. While they are not the same version it seems incredibly bizarre that a lower community version release would have features (that are very useful and I’ve never run into a bug with) that the higher release of enterprise doesn’t have. Basically, one more reason that enterprise isn’t getting my money -> either include it with both or don’t include it with either.

Regards,

Jeremy