Poll: what (minor) versions of MySQL should be supported by an open source MySQL related project?

April 2, 2010

I would like to get the community's opinion about supporting older (minor) versions of MySQL in open source projects.

If I were to develop some open source project, and a bug report came which only applied to MySQL 5.0.51 (but more recent versions worked fine), would I need to fix the code so as to support this older version?

How about supporting 5.0.22 (released almost 4 years ago, with almost 70 revisions since)? Would you expect an open source project to support this MySQL version because, say, this is the default version in your yum repository?

I would like to concentrate on the currently stable MySQL versions: 5.0 and 5.1. Versions 4.x are out of the question for me, and 5.5 is not yet GA.

Sure, it would be great to support everything. But also time and effort consuming. So, I would greatly appreciate your feedback!

What (minor) versions of MySQL should be supported by an open source MySQL related project?

View Results

Loading ... Loading ...

tags: ,
posted in MySQL by shlomi

« | »

Follow comments via the RSS Feed | Leave a comment | Trackback URL

8 Comments to "Poll: what (minor) versions of MySQL should be supported by an open source MySQL related project?"

  1. Roland Bouman wrote:

    I think it depends. If your project is geared towards end users, and should "simply work", then I would probably try to distribute my own version (not a fork, simply a stable copy that I know works).

    If that is not feasible, option 2 seems most appropriate. It's kinda like with browsers: although we wish IE6 and IE7 would die, for some users there are very little alternatives, so generally you must support them. If you're creating a typical internet applicattion, a strong factor for me would be what hosting companies have to offer. I imagine that would match what the distros are shipping, but my point is, you should look at what the user happens to be stuck with for whatever reason.

    If on the other hand your audience has the ability to install their one MySQL instance, or the product is unique enough for people to make an effort, I would stick with only the latest GA (and make sure while developing that it also works with the current beta, just to be ready).

    (For now I voted 2 which is closest to the first scenario)

  2. Peter Laursen wrote:

    For SQLyog we have this:
    http://www.webyog.com/faq/content/1/178/en/sqlyog-is-a-client-for-the-mysql-server-_-but-what-server-versions-are-supported.html

    .. but I am considering raising the 5.0 recommendation to 5.0.67 or higher (because of some specific bug that I do not remember right now).

    However a standard GUI client is likely supposed to be more generic than most applications. But we cannot totally abandon support for 4.x and even not 3.23. However some recently added features will not work with those as it would create extra effort and that we have decided not to do extra work to support version before 5.0.

  3. Rob Wultsch wrote:

    I think that:
    - MySQL 5.0 that is less than 5.0.67 is trouble
    - MySQL 4.X is not completely dead.
    - patching code to deal with issues in a single (old) version is insane.
    - breaking compatibility for no good reason (PhpMyAdmin, I am looking at you) is not useful.

  4. Mark Callaghan wrote:

    Support everything == commercial support or very popular project with users contributing patches. You won't have a very popular project initially. This will make some people unhappy, but they were probably not the users you need to grow a community.

  5. shlomi wrote:

    Thank you all for your valuable insight.

    The way I see it is that a decent consulting company will recommend a customer with 5.0.22 MySQL version to upgrade.
    Which means it is a good practice to have a fairly updated version.

    Since this is the open source world, I can put my own small weight into pushing towards good practices. So by saying "I only support recent versions >= x.x.x", I contribute a little bit into having more users using updated versions.

    Will look forward to more input.

  6. Anse wrote:

    I'm the author of HeidiSQL and I still get (few) complaints from users of MySQL 4.0, 4.1 and even 3.2x releases. Latest related issue complaints about an error message on 4.x servers which don't allow you to fire SHOW DATABASES if you don't have the SHOW_DB priv. Most such issues don't get a high personal priority by me. But if you ask if they should get supported at all I'd say yes, definitely. Only don't give them a too high priority. Additionally, in nearly all situations there are release dependent IF's and THEN's and ELSE's, also in the latest releases. If you read the MySQL manual, you will get a feeling for that - how often did you read "This statement was added in 5.1.foo, while it was behaving differently in 5.1.bar . So, HeidiSQL does it all by "if ServerVersion >= 50103 ..." and has fallbacks for older versions.

  7. Mark Grennan wrote:

    Most "users" don't know between release number. "Bigger is newer and better". DBA's either need a drop in replacement for the current release of the OS distribution. Redhat 5.4 is 5.0.77 at this writing. This is because they are using what the Sysadmin's will install or, the current supported version from MySQL (Oracle) because they are paying for the "real thing".

    Why? - Are you thinking of a fork that would be the MySQL equivalent of CentOS?

  8. shlomi wrote:

    @Mark,
    No, nothing of the sort. I'm developing a toolkit and a monitoring utility for MySQL, and am encountering issues with older versions.

Leave Your Comment

 
Powered by Wordpress and MySQL. Theme by openark.org