After hearing rumblings that a new release model was coming and then announcements that a new model was coming, I took the time  to watch the MySQL University session on it Thursday. I have thought for a long time that previous method of release management was less than perfect for MySQL Server resulting in long time periods between “GA” releases.

After listening to the session I have a great deal of hope that this will be a very positive change. I would recommend that you go listen to the session when it is posted (the pdf of slides are available but not the dim dim recording yet). It is very thorough. The basics are that server development is being moved to what is called a “Milestone Release Model”. These milestone releases will occur every three to six months and it is planned that they be of RC quality. Not every milestone will turn into a GA release. It seems to me (although I am not completely clear on this) that a GA release will occur every two or three milestones — which means a new GA occurs every year to eighteen months which is much more manageable than some of the previous release cycles.

How do you increase the GA release rate while not increasing the number of bugs? A significant way would be release fewer “major features” with each GA. If you are only incorporating two or three major features with a GA release it becomes much more manageable. In addition features won’t enter the “trunk” — the code that is at least RC quality — until the major bugs have been worked out. There are branches off this trunk for the development code.

Another important point is that while the milestones have specific features planned for them (say online backup), they are not set in stone. Rather than requiring that a certain feature is “shipped” with a milestone, a feature can be pulled from a release cycle in order to insure that the milestone is reached within the determined time. To me, this is a fantastic feature of this model. Why should any one feature hold up the entire process just so it can stabilize and be included? Stabilization/bug fixing of those features can (and will) take place in a separate branch if I understand correctly. Once a feature becomes more stable it could be included in the next release cycle.

Where does this leave MySQL server 6.0? I am afraid that 6.0 is going to become the orphan of the MySQL world. The May the 22nd announcement of the 6.0.11 release contained this:

"6.0.11 will be the last release of 6.0.  After this we will be
transitioning into a New Release Model for the MySQL Server"

The good news is that it is planned for the features of 6.0 (online backup et al.) will rolled into future server versions. Just as an interesting aside, when looking up the above quote I discovered the change notes for 6.0.12 which is labeled as “not yet released”.

The initial milestones have already been named:

• summit
• azalea
• betony
• celosia

Summit is the current milestone where work is occurring – it evidently began in April. I assume this was in conjunction with the announcement/release of MySQL Server 5.4 at the user conferenece. Azalea, the next milestone, either begin in late May or in June (it wasn’t totally clear to me). All the details are available in the university session. I would highly recommend that you take the time to view the session so you have a good understanding of the new development model.

All in all, I think this is going to be a good step for MySQL Server. According to information I have received, Oracle/Sun is trying to work more with the community to include them in the process. The process should make it easier for community contributions to be included. Not only that, with this model, it shouldn’t take two plus years for any community contributions to be included.

This is a win for everyone as far as I can tell, if things work out as planned. The end-user/customer gets new features when they are ready without waiting for other features to stabilize, the community gets a model that should be more open, Oracle/Sun gets more contributions from the community and the incredible 37 month release cycle for MySQL 5.1 is a distant memory. The internal developers will potentially get to see their work “out in the wild” much sooner.

Change for the sake of change is almost never good. But this a case of change where it is needed. My thanks to those involved in making this happen!