Ryan — except for pages like “learn more” (for instance the “learn more” page for the MySQL Query Browser and other GUI tools) that don’t even include a direct link to download. Instead, you have to “learn more”, decide “hey I like this product! I want to download it!” and then somehow realize you have to click “downloads” and then “GUI Tools”.

Would be much easier if they just had a “download now” link off the “learn more” page.

I think our problem as a community is that it’s difficult to tell the difference between MySQL’s marketing FUD spread in order to get people to buy the licensed version, and what’s actually happening from an engineering and community standpoint.

I see the reasoning behind MySQL’s decision, but I think the basic point here is that the naming/numbering scheme is not intuitive to the public. When I see “MySQL Cluster 6.2″, I presume that it has some relation to “MySQL ‘regular’ 6.2″. However, the current situation means that at some point (years from now probably) there will indeed be a “MySQL ‘regular’ 6.2″ with absolutely no relation to “MySQL Cluster 6.2″.

The purpose of product names and version numbers is to convey information in a rational fashion to users, hence why many products have internal codenames to convey the same to internal developers when there is a mismatch between internal practices and external understanding.

Its fine to have distinct products and versions, but by putting the version of this new product close enough to the existing one to cause confusion — but far enough apart to eliminate correlation — is distracting regardless of internal logic.

For instance, if MySQL Cluster 6.2.15 is based on MySQL ‘regular’ 5.1.24, then I would adopt the naming scheme MySQL Cluster 5.1.24-Cluster1 or something like that. But of course its your show.

Also, I would prefer the following name if possible: Sun Java MySQL Cluster Server Forte 10: Community Edition with NetBeans.

–
Simon

As several of us who work with Cluster have already stated here and elsewhere, the “6.2″ derives from the version number for the NDB storage engine, which has existed in 6.1, 6.2, and 6.3 branches since well before Sun acquired MySQL. This versioning reflects actual, non-trivial feature changes and additions.

But do check out the Cluster changelogs and Roadmap section in the MySQL 5.1 Manual and judge for yourself. I think you’ll agree that there really is a logical and functional basis for these designations, and they’re really not just some marketing gimmick.

After all, we could have called the product “MySQL Cluster 10″, “MySQL Cluster 2008″ or even “MySQL Cluster XP”, right? :)

cheers,

Jon Stephens
Sun Microsystems / MySQL Documentation Team

Not sure what “snafu” you’re referring to – there will be a MySQL 5.1 GA release in the near future, and InnoDB is expected to be one of the storage engines available in that release. Even if, for some reason, we could not include InnoDB – and I’d like to emphasise that at this point in time there is *no* reason for us not to include InnoDB in any MySQL Server release – this would definitely not stop us from doing a MySQL 5.1 GA.

NDBCLUSTER has been branched off from mainline MySQL in order to allow for a faster and more flexible development cycle for that storage engine, but it will periodically be sync’ed up with mainline MySQL 5.1 – this is why MySQL Cluster releases now have 2-part version strings, so it’s easy for users to see when this has happened.

If there’s anything in our documentation that suggests otherwise, please contact us directly and let us know what this is.

Jon Stephens
Sun Microsystems / MySQL Documentation Team