When I stepped into my current job as Senior MySQL Architect in
the summer of 2007 one of the first things on the agenda for
discussion was the development model. We had released 5.0 almost
2 years ago and we were still more than a year from releasing
MySQL 5.1. The model we used for developing MySQL 5.0 and MySQL
5.1 didn't work as well we wanted. So we had many discussions on
how to improve this model.
A quick step 5 years forward to today, we are now using the
Milestone release model and are just about to release the second
GA version that have been developed using this model.
Differences in old and new development model
So what is the main difference between the new development model
and the old development model?
I think the most important attribute of our current model is that
the development tree always have to be in a releasable state
every 2-4 months and this releaseable state have to be possible
to bring to a GA version in around 6 months of stabilisation
period. Our definition of releasable state is that the quality is
at Release Candidate level. The old model effectively only
required a releasable state when the version was reaching Release
Candidate state since also in the beta stage new features were
added, so a releasable state was only reached every 2 years
instead of every 2-4 months.
Impact on new code in MySQL
So what does this mean for how we need to develop new code in
MySQL. It means that new code must be added in fairly small
chunks, even more it means that the new code cannot be too
intermingled with old code since that would introduce too many
new bugs. So if we need to add a new feature in an area where the
complexity of the MySQL Server is high, then we first need to
reengineer this area before we can proceed pushing the actual new
feature. So in a sense the highest priority is always given to
maintaining a stable development tree. In the past to get a new
feature into the MySQL Server could sometimes have higher
priority than the stability of the development tree.
So interestingly, by prioritizing tree stability before new
features, we are able to develop more new features! But we are
not necessarily able to develop specific new features as quick as
we want sometimes. If a new feature requires tampering with
complex MySQL Server code, then it might require a number of
preparatory projects before they can actually be turned into a
real feature. But anything that can be done outside of the
complex parts of the MySQL Server can be added quite
quickly.
Development of major features in new model
How does one handle addition of new major features in this model.
The main consideration is that all new code must be fairly well
structured. So when adding a new feature we can't simply start
coding along, we first need to consider if the current code
structure can be used to develop this new feature. As an example
one of the last things added in MySQL 5.6 was a split of
LOCK_open. If we would have tried to add this feature in earlier
versions of the MySQL Server we would have had a new feature that
touches many functional parts of the MySQL Server and it would
have been introduced a significant set of new bugs to fix before
any new GA version could have been released. Instead we went
about things differently. First a number of reengineering
projects isolated the main feature of LOCK_open to only protect
metadata operations on tables and caching of metadata in
connections. When these steps were completed about halfways
through the MySQL 5.6 development, then it was very
straightforward to make the actual split of LOCK_open in a fairly
small patch which was a safe change.
Inspiration to new development model
Our selection of this new development model obviously was
inspired by lessons from other successful open source projects
such as the Linux kernel.
Change from old to new model
The change from the old model to the new model were probably the
most difficult part. At the time of the change we had a new
development tree which had some fairly significant new features
implemented in it. But the tree was very far away from getting to
a releasable state, so the tough decision was taken to restart
development with a new tree based on the MySQL 5.1 development
tree. This tree was the start of development using the new
milestone model. The features from the old development tree was
step by step moved over to the new development tree. This process
actually took a few years since there are very high quality
requirements on new features making it into the new development
tree. But now we've moved all features from this old development
tree that we will move, some of the features have been dropped or
simply completely reimplemented.
Impact on future MySQL development
So what does this mean for current and future MySQL development?
In MySQL 5.6 we added 200 new features, so obviously the new
development model leads to a high pace of new interesting changes
that will benefit our users and customers. We expect that the
development model will continue to benefit us and that we will
continue delivering new interesting features at a high pace to
the MySQL community. As an architect I am proud to see how the
MySQL development team continously improves the MySQL
architecture and thus making it possible to add new features at
an even higher pace.
Oct
08
2012