Where did 5.0.79 enterprise come from?

While updating the mirror last week I was surprised to see that the newest MRU MySQL release is numbered 5.0.79. Previously enterprise releases had even numbers and community releases had odd numbers. I posted the question in #mysql-dev and HarrisonF was kind enough to explain it all.

MySQL 5.0 is running out of version numbers. There are limitations in mysql_get_version(), the executable comment syntax, and other places that mean MySQL can only have two digit release version numbers. MySQL Enterprise has started using odd and even version numbers to extend the life of 5.0.

This raises a few questions. What will happen to 5.0 when it runs out of release numbers? Is community going to be sacrificed to give enterprise more versions to use? Are the version restrictions going to be fixed in the future? For example if a feature is implemented in a community release the executable comment version syntax isn’t suitable for preventing it from being executed in a newer enterprise release because the version scheme doesn’t differentiate between enterprise and community.

I think this is now rock solid proof that there were too many features packed into 5.0 and it was released too early. I hope there will be more major releases in the future with fewer features so these problems are prevented. By the way the advanced vs pro enterprise binaries add a whole new layer to the MySQL version issues.

8 Comments

  1. Hi!

    “I think this is now rock solid proof that there were too many features packed into 5.0 and it was released too early.”

    mm, can’t say I agree…if rock solid proof of anything, I’d pick “shortsighted decision in allocating just two digits for that version number”

  2. Arjen Lentz says:

    Nice of Harrison to explain.
    Considering the situation, this might have been something say Kaj or Giuseppe could’ve blogged about, to pre-empt this kind of question.

  3. Todd says:

    Hi Eric!

    The revised numbering was briefly mentioned by Kaj, although it doesn’t go into significant detail:

    http://blogs.mysql.com/kaj/2008/12/01/mysql-51-release-schedule/

    “Is community going to be sacrificed to give enterprise more versions to use?”

    http://www.mysql.com/about/legal/lifecycle/ tells you exactly when Community 5.0 stops getting released, and it’s not too far in the future.

    “By the way the advanced vs pro enterprise binaries add a whole new layer to the MySQL version issues.”

    How so? You get 5.1.33 pro, or 5.1.33 advanced. The same thing has existed in OEM builds for some time (“classic” without InnoDB, “pro” with). Why does the creation of a new Advanced Server with a different feature set, but based on the same code, affect the number of versions available in any way?

  4. Eric Bergen says:

    No, you get 5.1.33 community, 5.1.33 pro or 5.1.33 advanced. All with a different set of features. The executable comment syntax only knows version numbers, it doesn’t know anything about community/pro/advanced.

  5. Eric Bergen says:

    Sorry 5.1.whatever community, 5.1.33 pro or 5.1.33 advanced. The version number can no longer be used to know if a specific feature or change exists.

  6. Todd says:

    Hi Eric,

    Still not understanding your comment about “executable comment syntax”:

    Welcome to the MySQL monitor. Commands end with ; or \g.
    Your MySQL connection id is 1
    Server version: 5.1.33-enterprise-gpl-pro-log MySQL Enterprise Server – Pro Edit
    ion (GPL)

    Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

    mysql> select version();
    +——————————-+
    | version() |
    +——————————-+
    | 5.1.33-enterprise-gpl-pro-log |
    +——————————-+
    1 row in set (0.03 sec)

    I’m sure I’m missing your point.

  7. Todd says:

    Ah, right. That’s been the case for OEM builds for sometime, now.

    The version number tells the code baseline, the “pro” or “advanced” tells you what options were baked into the build.

    It was also true in 5.0 with Cluster.

  8. Eric Bergen says:

    The specific example I ran into was adding new variables to mysqldump output. If my patch to add a variable to control the slow query log:

    http://ebergen.net/wordpress/2007/07/03/set-sql_log_slow0-to-control-the-slow-query-log/

    Was included in mysql community. It’s execution would be controlled by versioned executable comments. For example let’s say my patch is included in 5.0.77 community the comment would look like:

    /*!50077 set sql_log_slow=0*/

    If I try to restore that dump file on a newer version of mysql enterprise it’s going to be broken because while the version is technically newer enterprise wouldn’t know about sql_log_slow because it was only included in community.

Leave a Reply