With 130 entries in the “MySQL” category and no MySQL-related subcategories, my blog had become impossible to search and navigate easily.

And thus I created a number of new categories for the MySQL entries within my blog. They’re listed in the left navigation bar, below the months, as well as below:

• MySQL Server, MySQL Cluster, Falcon
• Connectors: PHP, Ruby on Rails
• Tools: GUI, MySQL Workbench, MySQL Proxy
• Events: MySQL Users Conferences
• Licensing: GPL
• Architecture of Participation, Summer of Code, Virtual company
• Other: Release Policy, Documentation, Use cases

I hope this will make my blog more (re)usable.

(The picture is from this summer, when navigating the way up the Großvenediger, a 3662 m high mountain in the Hohe Tauern region of Austria.)

MySQL has introduced Previews as a new way of delivering features for early testing by our community.

Previews are for testing of features, not of versions. The two previews we offer today are the Falcon Feature Preview based on 6.0, and the GIS Feature Preview based on 5.1. However, the version number as such is not intended by us to set any expectations on when the feature will be in a production version. For instance, Falcon is going into the 6.0 code base, but the GIS geographical data won’t be in before 6.1 (although the preview is based on 5.1).

Previews are by definition a bit “rough around the edges”. They have no inherent level of maturity — they aren’t pre-alpha, or alpha, or beta, or RC, or GA. They are a new way to do “release early & release often” for those who want to get things early, without MySQL tying itself into a promise on the specific delivery release.

Falcon 6.0.4 is available immediately in the preview release and soon will be part of a formal beta. If you want it immediately, go get the preview version!

Our purpose of having previews is to make new features available for those who want early access. That way, we hope for more community testing. For our users, Previews are meant for testing only, absolutely not something to use in production. It’s a new way for us to release early & often for experimentation, learning, and testing.

Later on, I hope we will do other feature previews for storage engines or specific features.

Links:

• Falcon Feature Preview
• GIS Feature Preview
• Download MySQL 6.0
• MySQL 6.0 in a nutshell
• New features in MySQL 6.0.3
• Documentation: The Falcon storage engine
• Forge: The Falcon storage engine
• Forge: MySQL Tutorials (look for the Falcon header)

First of all: Thank you for your positive feedback on the MySQL 5.1 Errata Sheet!

While I never doubted that publishing the 5.1 Errata Sheet was the right thing to do, I had expected a more mixed feedback. It turned out the feedback was very grateful. So thank you for your encouragement

• Kevin Burton for commenting in Jay’s blog
  

  “This was a big win guys. Good work.We were going to deploy 5.1.x in out or production slave configurations just to test the reliability but this give us a lot more confidence in this release.”

• Baron Schwartz for commenting in my blog
  

  “Kaj, this is VERY helpful. I just discovered the character set issue with mysqldump myself last week.This is a big step forward in quality, from the user’s point of view. Now it’s much easier to see the state of things.”

• Peter Zaitsev for explaining some background in the blog entry “Making bugs public - good job MySQL”

The Errata Sheet had somewhat of a difficult birth process, as our pompously titled “Release Philosophy” page optimistically refers to the ideal situation of “no known critical bugs”. If we follow that policy, there is no need for an errata sheet, is there? The Errata Sheet should by definition be empty.

But it isn’t.

And it wouldn’t have been, for the last four years, had we just had sufficient awareness of critical bugs, and a policy of publishing them.

The only logical conclusion from our Reality Check was that wishful thinking must stop, and we need to do the right thing under the circumstances: Get the best possible quality releases out with the given resources, and set the expectations of our customers and users according to what we can and will deliver.

And hence we appointed a cross-team working group, the “Release Criteria Committee“, which is defining both external and internal processes and policies when it comes to

• releasing new releases in general
• moving from one maturity stage to another
• dealing with bugs of all kinds
• aligning MySQL release policy documentation with reality

So let’s first look at the circumstances:

• Resources are finite: There is only so much time in a day, and there are only so many developers around to fix bugs.
• Timely releases have value to our users: Earlier access to bug fixes. Earlier access to new features. Earlier testing of both, i.e. faster convergence. Reduced guesswork about when the next release will be.
• Zero critical bugs is impossible: Sure, zero bugs is desirable. And at times, we internally glorify MySQL’s past, with “production level alpha releases”. Those were the days, but those days also had less complex and less interwoven features, and fewer developers to manage.

As such, it is MySQL’s responsibility to create a release policy that is aligned with the needs of the customers and the user base. This will involve a number of difficult judgement calls. However, we do think that we’ve got a lot to learn from our customers and users, when it comes to defining the best possible release criteria. So I am inviting your input.

To structure your thinking and the work, let me briefly explain some basics:

1. We have four maturity levels: Alpha, Beta, RC and GA.
1a. Alpha is for testing and development only. Features are added, and
syntax may change. (*)
1b. Beta means feature-freeze. We fix bugs. (*)
1c. RC or Release Candidate needs solid criteria. RC has some industry definitions, and is the final stage prior to GA.
1d. GA or General Availability means the version is for production use. The name GA is somewhat silly for Open Source products, as even alpha releases are available for the general public.
(*) These are my own simplifications, and our work group may refine them.

2. Bugs are described by their Severity, Defect Classification, Impact, Risk To Fix, and Effort. They may have even more dimensions.
2a. Severity describes the damage from the original user (bug reporter) point of view. The most severe bugs are about crashes, security problems and corruption, without any known workaround. The least severe refer to unpleasant but documented behaviour, i.e. feature requests. From the severity of the individual original reporter, we derive the Defect Classification, which attempts at being a neutral classification across our user base.
2b. Impact refers to how many users may be affected. They range from
the entire user base, all the way to corner cases that affect only users of a particular feature on one platform.
2c. Risk To Fix and Effort refer to the difficulty of fixing the bug. A bug fix may destabilise the code (i.e. introduce more problems than it fixes), requiring postponing the fix to a later version. And the time for fixing the bug may vary (influencing the complexity of reviews).

Some of my personal thinking on the release policy is as follows:

(i) Maturity changes need quality criteria.

• Progressing from Alpha to Beta is not useful if most testers find the same elementary critical bugs; basic usability should exist
• Progressing from Beta to RC needs for the impact of critical bugs to be very low
• Progressing from RC to GA needs the impact of critical bugs to be even lower
• Hence, I advocate quality based (not time based) release criteria for maturity changes

(ii) New releases within the same maturity level need different quality criteria (from above).

• Regression bugs must be avoided (what worked in release n must still work in release n+1) (**)
• Beyond that, we mainly need for the quality of release n+1 to be higher than that of release n. In practice, if you look at today’s (10 Nov 2007) version of the Errata Sheet, you will see a lot of bugs annotated with “Already fixed in 5.1.23″, while others have “Target fix: 5.1.23″. “Let’s not wait until we can cure all illnesses, before handing out the medicine we already have!” is my logic.
• Hence, I advocate mostly time based (seldom quality based) release criteria for new releases within the same maturity level
• (**) By “regression bugs” I mean unintentionally changed behaviour, i.e. pure bugs. There may be situations where behaviour has to be consciously changed to enable the fixing of a bug.

(iii) Simplicity rules.

• The definitions of the dimensions that describe bugs must be as simple as possible.
• The rules triggering maturity changes must be as simple as possible.
• It should be easy at any point in time for us to evaluate whether we should change a maturity level (as opposed to being a negotiation between self-proclaimed advocates of quality and timeliness, respectively)

(iv) Timeliness has a value, and RC criteria may differ from GA criteria.

• Some claim that by definition, an RC must fulfill all GA criteria except the exposure to wide user base testing
• Others (like me) think that it’s in the best interest of the user base to converge to a GA quicker, through marginally relaxed RC criteria, whereby we can fix the remaining less-critical bugs in parallel with the RC getting exposed to massive parallel testing by the user base

When we (the members of our Release Criteria Committee) think we’re done, we’ll upgrade our Release Policy (and, while we’re at it, no longer pompously describe it as a Philosophy). We’re working at a fairly hectic pace, and expect to be done within weeks rather than months.

In the meantime, your input is welcome!

As indicated last week, we have decided to start producing a condensed report of outstanding issues in our current development release, MySQL 5.1.

This list is now available as part of our reference manual at dev.mysql.com/doc/refman/5.1/en/open-bugs.html.

The list is updated daily based on the then-current status in our bug database.

The purpose of the list is to make it possible for our users to more easily make an informed judgement about whether our development release is ready for them to test and use. While the corresponding bugs have already been openly and publicly available for searching in our bug database, I hope this list is easier to navigate, as it is compiled into one web page that is sorted into categories such as

• C API
• Client
• Connector/J
• Server: Backup
• Server: Charsets
• Server: Cluster
• Server: Events
• Server: I_S (Information Schema)
• Server: InnoDB
• Server: Partition
• Server: RBR (Row-based replication)
• Server: Replication

Hence, if you’re into using Row-based replication, read through the corresponding section. Our goal is to make it easy for you to know whether any of the outstanding bugs are relevant for you.

The list also contains target fix releases (with 5.1.23 currently being the next one), and links directly into the bugs system for detailed inspection of the bug description.

A good two weeks ago, MySQL 5.1.22 was released. MySQL 5.1 is a new release of MySQL Server, with new features like

• partitioning (likely the top feature in 5.1)
• events (”crontab” triggers in the database)
• row-based replication
• table logs
• some XML functions

and also with major bug fixes, such as the AUTO_INCREMENT table-lock contention in InnoDB (fixed now in 5.1.22), as well as early indications of performance improvements of up to 20 % - 40 % on dual cores in some scenarios.

Jay Pipes has written an overview that compresses all of the pointers to 5.1 into one article, MySQL 5.1 Article Recap. I recommend you read it. I also recommend the manual section What’s New in MySQL 5.1.

With 5.1.22, MySQL also changed the maturity state to “RC”, Release Candidate. Looking at our own Support Policies, Release Candidate (aka Gamma) release is defined as follows:

Release Candidate binaries, also known as Gamma releases, are believed stable, having passed all of MySQL’s internal testing, and with all known fatal runtime bugs fixed. However this release has not been in widespread use long enough to know for sure that all bugs have been identified.

However, we recognise that this particular RC does not fit the definition exactly. We still have some fatal runtime bugs left. We are producing an errata list of these, and expect to have the list ready and published on by 23 Oct 2007. We know that we should have published this list together with the RC itself, and we are now working as fast as we can to fix this.

We know we have thus released our RC too early according to our own standards, and we are doing our best to fix it. We apologise for any inconvenience/miscommunication and are working on improving our internal guidelines to ensure it doesn’t happen again.

That said, 5.1.22 is a great release, one that we’re proud of, and very likely worthy of your attention!

With the my blog entry yesterday on Refining MySQL Community Server, did anything really change? If so, was it for the better or for worse for the community?

My answer is “not much”, and “for the better”, but feel free to disagree.

Judging from some reactions in the community, a lot changed, and for the worse.

• Mike Kruckenberg feels that MySQL takes another step away from Open Source, through no longer publishing the sources for the Enterprise incarnation of the MySQL Server.
• Jeremy Cole claims that the MySQL Community split is officially a failure, and that MySQL fundamentally misunderstands their community.

Strong words.

So let me expand on the “not much” part:

The negative reactions that I experienced on the #mysql-dev channel in the Freenode IRC chat stem (like Mike Kruckenberg’s blog) from the removal of the source code of MySQL Enterprise Server from ftp.mysql.com. I argue that while this may feel or appear like a step away from Open Source, the real effect on the core MySQL community member is minuscule. And this is by design. We don’t intend for the change to adversely affect core MySQL community members’ usage. What we do intend is related to positioning: MySQL Community Server is for our users, MySQL Enterprise Server is for our paying customers. We want people to associate MySQL Enterprise Server with a commercial relationship to MySQL as a company.

Hence, we thought about what we could do to encourage the use of MySQL Community Server, in particular by the Linux distributions. Part of that is discouraging the use of MySQL Enterprise Server, and that’s why we set a signal by removing the source code of the Enterprise incarnation of the MySQL Server code.

But I want to underline that we also took a number of positive measures — carrots, if you will — which brings me to the “for the better” part.

First and foremost: We stopped adding new features to a GA release. No more new patches to 5.0. Adding new features to 5.0 is the “that” that I was above all referring to in IRC when saying (as now quoted by Jeremy)

<kaj> JeremyC: Our past 10 months since Oct has been a struggle to make that work, and we’ve failed

Having a stable release which gets new features is like squaring the circle. It’s not doable in Euclidean geometry. This is also where I feel Jeremy’s pain. There are plenty of reasons to want to have new functionality into a stable release, without the burden of the destabilisation introduced by other new functionality.

As I understand Jeremy’s non-Euclidean solution (and there are other geometries than that of Euclid), he wants to pick and choose individual patches, and build an abundance of binaries with a free combination of those patches. While that may be technically feasible, it gives MySQL Community Server a different role from the one intended by MySQL AB. MySQL AB gave two mandates to MySQL Community Server: being experimental, and being the main one used by the MySQL user base. The mandate of MySQL Enterprise Server was the opposite: being stable, and being the one used by customers entering a commercial relationship with MySQL. That equation is the other “that” which hasn’t worked in the past ten months at MySQL AB.

Now, yesterday’s announcement recognised that these requirements are conflicting. That’s where we failed. The community doesn’t want to merely experiment, it wants to use a stable version. And the changes announced yesterday are about making Community Server stable. On top of that, we increase the predictability and planned frequency of Source releases (which we do to encourage Distributions to use MySQL Community Server). Jeremy correctly points out that the frequency doesn’t change much compared to our actual track record on release frequency during the last 6-7-8 months. Personally, I wouldn’t necessarily count it to our disadvantage that we’ve released more frequently than planned (which was twice a year). The more-frequent-than-planned releases is another indicator of the failure of the double mandate (”experimental” plus “main version”), that yesterday’s announcements are supposed to improve.

Another solution, which I suppose would have pleased Jeremy, is to fix the situation by removing the mandate of MySQL Enterprise Server to be associated with a commercial relationship with MySQL. Then we would have one stable and one experimental variety of MySQL Server, regardless of the dimension of paying vs. non-paying. That would dissociate the brand of “MySQL Enterprise Server” with paying-only. And different branding of servers, in turn, is one of the basic current assumptions of Community versus Enterprise. I do understand that this distinction is not one that the Community particularly cares about. However, indirectly, a successful commercial company behind MySQL fuels the virtuous circle from which the community benefits in the form of new GPL features developed by MySQL AB.

Speaking of GPL: I want to make it perfectly clear that we have no intentions of moving MySQL Enterprise Server to another license. Yes, we are evaluating GPLv3 instead of GPLv2, but our plan is for both Community Server and Enterprise Server to remain GPL.

So in summary, I do say “not much” has changed. We have recognised some impossible requirements on the Community Server, and made the difference between Enterprise Server and Community Server consist mainly of the packaging (release schedule and availability). Same features, same bug fixes, different schedule, different branding.

I hope to now focus on making the best out of both Enterprise and Community server, feeding the virtuous circle of open source software.

Back in October 2006, we introduced MySQL Community Server. Since then, we’ve learnt a thing or two, spent many man hours discussing how to improve our processes, and are now refining the concept. We feel that we’ve come up with some good middle-ground that fulfils not only our company interests but fosters community use and growth as well.

The changes are in the areas of release policy and stability of MySQL Community Server and in the availability of MySQL Enterprise Server.

The changes start from the question: “How can we better target MySQL Community Server to the community and MySQL Enterprise Server to the paying customers?“. Many of them originate from our ongoing discussions with the Linux Distributions, some of whom have been distributing MySQL Enterprise Server to their user base, since MySQL Community Server hasn’t conformed to their needs of feature stability and release schedule.

Our intention is for MySQL Community Server to be very good, and for MySQL Enterprise Server to provide further value on top of that. The five changes, in short, are:

1. New features and community contributions will go into the next development tree. The new features will not be applied to a current GA release, ensuring stability for the Community Server. At the time of writing, the development tree is MySQL 5.2.
2. There will be at least two yearly “mature GA” (currently MySQL 5.0) binary builds. They aren’t scheduled, but usually triggered by grave security vulnerabilities.
3. When a version of MySQL initially goes GA (as 5.1 soon will), the company will release binary builds of the new GA product every month for a period of several months until it reaches a point of suitable stability/maturity to be considered a “mature GA” release — as described above.
4. There will be four yearly “mature GA” (currently MySQL 5.0) source releases, predictably scheduled, to be released once every quarter. These will be ideal for use by distributions shipping MySQL.
5. The current Enterprise source tarballs will be removed from ftp.mysql.com. These will move to enterprise.mysql.com, and will be available for our paying subscribers only.

Let me expand upon the first and the last items.

Community contributions: As I know this is a topic important to our contributors and potential contributors, let me provide an example. I confess: We’ve been bad at incorporating new features. We haven’t entered much more significant than SHOW PROFILE, and it took many months and several builds to mature. And we cannot continue with this practice of applying patches to a stable release, because new features will destabilise the release. That’s what we’ve been hearing from both distributions and contributors. We’re listening, and we’re learning. By no longer going for the impossible (adding features to a feature frozen release), we hope to change this dynamic for the better.

Enterprise source code availability: I expect three questions, “Why?“, “Does this conform with the GPL?” and “What keeps a paying customer from building and posting Enterprise binaries?“. The rationale is to underline the positioning goal of “Community Server for community users, Enterprise Server for paying users”. And the GPL requires us (like anybody else) to hand out the code to those whom we give the binaries, which in the case of MySQL Enterprise Server is just the customers. So it does conform to the GPL, something that we’ve verified with the FSF to eliminate any doubt. And as for the third expected question, the answer is “Nothing”. Still, we feel that most business users will see the value of a MySQL Enterprise subscription that offers regularly-reliable software updates directly from the ’source’, along with premium 24×7 technical support and proactive monitoring/advisory tools.

To finish off, let me repeat a number of basic facts which stay unchanged:

1. both the Enterprise Server and the Community Server remain licensed under the GPLv2
2. MySQL Enterprise Server has Monthly Rapid Updates (MRUs) and Quarterly Service Packs (QSPs), i.e. binaries delivered to our customers; building these binaries is a service for paying customers only
3. bugs are first fixed in MySQL Enterprise Server builds, and while updates are delivered quicker and more frequently to paying customers, bug fixes are also added to the next source and binary builds of MySQL Community Server as stated above
4. when scheduled, we build Community binaries for all platforms
5. community binaries and sources are still available for download at dev.mysql.com/downloads
6. all source trees are still available via BitKeeper
7. the Enterprise Server is close to a full subset of the Community Server

With these changes that are intended to simplify life for the Linux Distributions that distribute MySQL, we hope to better serve the MySQL user base, while continuing to provide additional value to our paying customers in the form of more frequent, scheduled binary bug fix releases.

If you have any questions with regards to this, please do not hesitate to reply via email to community@mysql.com.

Today at OSCON, MySQL co-founder Michael “Monty” Widenius and I presented the “State of the Dolphin” lightning talk.

My slides for this preso weren’t too graphic, which makes them all the easier to reuse in this blog:

Use our new software!

• Use MySQL 5.1, it‘s soon going RC
• Use Falcon, it‘s soon going Beta (new transactional storage engine, faster than InnoDB on large servers)
• Use MySQL Workbench (ER Tool), Now Beta
• Use MySQL Proxy, just released
• PHPers: Use mysqlnd (Native Driver)

Go test MySQL 5.1!

• We‘re happy with the quality
  • More stable than 5.0 was four months after GA
  • RC happening very soon, GA within a few versions after that
  • A better MySQL 5.0 (thousands of small fixes)
• We‘re happy with the new functionality
  • Table / Index Partitioning
  • Row-based replication – Transfers data instead of commands
  • Full-text indexing parser plugins – Flexible full text search
  • Disk-based Data Support for MySQL Cluster
  • Replication Support for MySQL Cluster
  • XPath Support - helps any customer wanting to better navigate and search XML documents stored in MySQL
  • Internal Task Scheduler (Events)

Other goodies coming soon (5.2, 6.0, …)

• Global Backup API
• Falcon and Maria (MyISAM++) storage engine
• Further new storage engines
• Hash & Merge joins (faster subselects)
• Federated tables over ODBC
• Foreign key support for all engines

Participate in our Development!

• Report bugs! Test them! Submit patches!
• Hang out on Freenode IRC #mysql-dev
• Subscribe to commits@lists.mysql.com to see our code reviews
• Attend MySQL University, the foremost education for MySQL developers (of C/C++ code, not apps)
• MySQL Forge: List your MySQL apps! Upload your code snippets! Fix the missing documents!
• Go visit MySQL Forge Worklog
  • Voting for best features starting soon

Hiring!

We are hiring outstanding C/C++ developers with systems or database engineering experience.
Visit www.mysql.com/jobs or email resume to jpugh@mysql.com

MySQL is indebted to the Software Freedom Law Center for very good advice and insight on how to combine Free Software with a viable business model. SFLC provides legal representation and other law-related services to protect and advance Free and Open Source Software. Founded in 2005, the Center now represents many of the most important and well-established free software and open source projects.

Professor Eben Moglen, SFLC director and FSF legal counsel, has provided us with profound guidance over the years. We have tried to give something back through our work in the GPLv3 Committee B, but our time resources as a small company are limited in comparison to our fellow committee members.

In recognition of Eben’s help and as a token of our appreciation, we’ve made a small donation to support the continued work of the SFLC. We encourage others who build their business on free software to do the same.

Thank you, Eben!

Finally!

We have a release of MySQL Community Server that contains community-provided contributions and it is ready for your download in binary form.

Thanks to Jeremy Cole for providing us with the SHOW PROFILE patch. Quoting our Reference Manual at http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html:

SHOW PROFILES

SHOW PROFILE [type [, type] … ]
[FOR QUERY n]
[LIMIT n [OFFSET n]]

type:
ALL | BLOCK IO | CONTEXT SWITCHES | CPU | IPC | MEMORY | PAGE FAULTS | SOURCE | SWAPS

The SHOW PROFILES and SHOW PROFILE statements display profiling information that indicates resource usage for statements executed during the course of the current session.

Profiling is controlled by the profiling session variable, which has a default value of 0 (OFF). Profiling is enabled by setting profiling to 1 or ON:

mysql> SET profiling = 1;
SHOW PROFILES displays a list of the most recent statements sent to the master. The size of the list is controlled by the profiling_history_size session variable, which has a default value of 15. The maximum value is 100. Setting the value to 0 has the practical effect of disabling profiling.

All statements are profiled except SHOW PROFILES and SHOW PROFILE, so you will find neither of those statements in the profile list. Malformed statements are profiled. For example, SHOW PROFILING is an illegal statement, and a syntax error occurs if you try to execute it, but it will show up in the profiling list.

SHOW PROFILE displays detailed information about a single statement. Without the FOR QUERY n clause, the output pertains to the most recently executed statement. If FOR QUERY n is included, SHOW PROFILE displays information for statement n. The values of n correspond to the Query_ID values displayed by SHOW PROFILES.

The LIMIT n clause may be given to limit the output to n rows. If LIMIT is given, OFFSET n may be added to begin the output n rows into the full set of rows.

Some sample output:

mysql> SHOW PROFILES;
+----------+----------+--------------------------+
| Query_ID | Duration | Query                    |
+----------+----------+--------------------------+
|        0 | 0.000088 | SET PROFILING = 1        |
|        1 | 0.000136 | DROP TABLE IF EXISTS t1  |
|        2 | 0.011947 | CREATE TABLE t1 (id INT) |
+----------+----------+--------------------------+
3 rows in set (0.00 sec)

mysql> SHOW PROFILE;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| checking permissions | 0.000040 |
| creating table       | 0.000056 |
| After create         | 0.011363 |
| query end            | 0.000375 |
| freeing items        | 0.000089 |
| logging slow query   | 0.000019 |
| cleaning up          | 0.000005 |
+----------------------+----------+
7 rows in set (0.00 sec)

This information is also visible in the corresponding INFORMATION_SCHEMA.PROFILING table.

Unfortunately the SHOW PROFILE implementation as of 5.0.37 still has a small gotcha, that we will resolve for the next release: the MySQL command line client hangs if you issue the SHOW PROFILE command without having enabled the @@profiling session variable before. Hence, when you evaluate this new feature, make sure to enable it by issuing “SET @@profiling = 1;“ before.

In summary, the SHOW PROFILE patch provides a way for the MySQL Community Server users to get a more detailed understanding of where the response time is formed. Jeremy also contributed a patch to display the Uptime_since_flush_status status variable, which indicates the number of seconds since the most recent FLUSH STATUS statement. Thanks, Jeremy!

Looking beyond the community enhancements, MySQL Community Server 5.0.37 is our second full (source and binary) release of the MySQL Community Server since we made the split between the Community and Enterprise Version in October 2006. It includes all bug fixes applied to up to and including the MySQL 5.0.36 Enterprise Server. The prior MySQL Community Server 5.0.33 release early January 2007 was a source-only release.

The 5.0.37 release also resolves a crashing bug that could be exploited as a potential local Denial of Service attack. Thank you, Stefan Streichsbier from SEC Consult, who also informed us about this bug via our security@mysql.com mail address - he will send out a separate advisory about his findings.

We welcome and appreciate your feedback, bug reports, bug fixes, patches etc. as described on MySQL Forge on http://forge.mysql.com/wiki/Contributing.