Databases Reference
In-Depth Information
Which version should you use? This depends on your business more than on your
technical needs. You should ideally build on the newest version that's available, but of
course you might choose to wait until the first bugs have been worked out of a brand-
new release. If you're building an application that's not in production yet, you might
even consider building it on the upcoming release so that you delay your upgrade life-
cycle as much as possible.
MySQL's Development Model
MySQL's development process and release model have changed greatly over the years,
but now appear to have settled down into a steady rhythm. Oracle releases new
development milestones periodically, with previews of features that will eventually be
included in the next GA
7
release. These are for testing and feedback, not for production
use, but Oracle's statement is that they're high quality and essentially ready to release
at any time—and we see no reason to disagree with that. Oracle also periodically re-
leases lab previews, which are special builds that include only a selected feature for
interested parties to evaluate. These features are not guaranteed to be included in the
next release of the server. And finally, once in a while Oracle will bundle up the features
it deems to be ready and ship a new GA release of the server.
MySQL remains GPL-licensed and open source, with the full source code (except for
commercially licensed plugins, of course) available to the community. Oracle seems to
understand that it would be unwise to ship different versions of the server to the com-
munity and its paying customers. MySQL AB tried that, which resulted in its paying
customers becoming the bleeding-edge guinea pigs, robbing them of the benefit of
community testing and feedback. That policy was the reverse of what enterprise cus-
tomers need, and was discontinued in the Sun days.
Now that Oracle is releasing some server plugins for paying customers only, MySQL
is for all intents and purposes following the so-called open-core model. Although
there's been some murmuring over the release of proprietary plugins for the server, it
comes from a minority and has sometimes been exaggerated. Most MySQL users we
know (and we know a lot of them) don't seem to mind. The commercially licensed,
pay-only plugins are acceptable to those users who actually need them.
In any case, the proprietary extensions are just that: extensions. They do not represent
a crippleware development model, and the server is more than adequate without them.
Frankly, we appreciate the way that Oracle is building more features as plugins. If the
features were built right into the server with no API, there would be no choice: you'd
get exactly one implementation, with limited opportunity to build something that
suited you better. For example, if Oracle eventually releases InnoDB's full-text search
functionality as a plugin, it will be an opportunity to use the same API to develop a
similar plugin for Sphinx or Lucene, which many people might find more useful. We
7. GA stands for generally available, which means “production quality” to pointy-haired bosses.
