I prepared the release builds for 5.0.11 yesterday evening and they have been uploaded to the mirrors. All automated tests passed without error and my initial manual tests showed everything working. Nevertheless Tax found a show-stopper bug later today following our manual testing procedures.
The problem is located in the SQL generation code for tables. We introduced a new internal index type for foreign key index columns that is maintained automatically by the tool. This new type caused the generated SQL to be corrupt. We tried a simply fix today but were not able to fully solve it. We will take time tomorrow to properly fix the issue and I will trigger new build after that. Then it will take about 20h till the mirrors have catched up and we can announce the new release.
Sorry for the delay.
For all new contributors devoted to quality, FAQ was slightly updated with new section.
We are working hard on the next release of MySQL Workbench and are trying to follow our plan of getting a release out every second week. A lot of things have already been addressed, some new things came up. But we are clearly moving into the right direction and our investments in unit tests and UI tests seems to pay off as expected. More details in a post later this week.
I just sent out the mail to the mailing lists to officially announce the 5.0.10 release. I have added an additional page that will keep track of the changes we make and it is available here. The change log file is included in the source package as well of course.
I am curious how the level of regression bugs will be. For Workbench we have a unit testing framework in place as well as an ever expanding suite of UI tests. We are using TestComplete and as long as the tool does not crash itself (which happens quite a lot, sadly) it is quite useful to automated the UI testing.
Please keep testing and reporting bugs. We will keep working hard to fix reported issues as fast as possible.
We are just in the process of running the final 5.0.10 builds. If Johannes does not discover any last-minute major bug we are going to upload to the mirrors soon and the release will be available tomorrow. The complete build and packaging process is now fully scripted.
The community did an amazing job in reporting bugs – there were a lot of issues that slipped through the first release. And so did the team. 75 bugs were closed since the 5.0.9 release in just 9 days. If we can keep that pace we will reach RC even sooner than I expected.
A lot of P1 and P2 bugs have been closed, we still have a load of P3 + P4 to go and I hope the stream of bugs keeps getting in, so we discover all issues soon. My biggest concern is about some threading issues we seem to have in the core which causes “random” crashes. We will run stress tests to trace those down during the next weeks.
Ok, builds have finished, now the last QA test are taking place.
As most of you probably know now, Workbench supports two visualization modes: hardware & software based. Unfortunately automatic switcher was not in place by the time when beta version came out (will be fixed in a week), so some of you, who don’t have video subsystem supporting OpenGL v1.5, will encounter error on start when trying to run hardware based configuration. Note v1.5 is a minimum required version of OpenGL needed to start Workbench. You can get detailed information about your video subsystem using one of these tools: OpenGL-Extension-Viewer or GPU-Caps-Viewer. Both of them support export into xml file, so you can also easily attach your video configuration to your bug report when needed.
It has only been two days since I have announced the official Beta of Workbench and (after taking today off to do some snowboarding) I am amazed by the number of people who have already signed up for the Standard Edition Beta Testing Program.One question was asked by several people and that is, how often are we going to release new Beta builds? We are trying to release a build of OSS Edition and SE every 2nd week and always have the most critical bugs reported fixed.Edit: Please notice that the SE Beta Program has now been closed.Â
Today at 19:25 CET I announced the availability of the first official Beta release of MySQL Workbench.I wrote that this marks a milestone for my team and this is absolutely true. We have very high ambitions with this project for the years to come and getting the core of the implementation done right is crucial for any success. Sure there are still bugs, sure we still have to remove some rough edges but the core is there. And after 20 years coding since I wrote my first lines in Basic when I was 12, let me tell you – this core is right. And now we can stabilize and improve upon it.The last months have been quite a challenge for my team and myself. Working 50-80h weeks do mean serious compromises on your personal life but if you believe in something you are ready to walk the extra miles to get it done right.So at this point I would like to thank every member of the team (and the girlfriends who have been extra-forgiving) and all the people inside of MySQL who made this possible – you rock!We will continue to keep working hard for the next months to fix all bugs that our community and our SE Beta testers will report to get the tool stable and into RC and GA as soon as possible.MikeZp.s.: I’m sorry if this posting may sound a bit greasy but this was an emotional moment 🙂
I completed the Windows MSI installers yesterday. We are now using the WiX3 toolkit to create the Windows Installers from XML files. The built in preprocessor has been improved in WiX3 so we can now directly work with the XML files without preprocessing them with our own tool.
What is yet missing is the registration of the .wbm (Workbench Model) files to be opened with the Workbench application.
We discovered a problem with our native OpenGL support detection and therefore I added a 2nd shortcut in the Start Menu called MySQL Workbench 5.0 OSS (Software rendering) that will force software rendering with the -mesa command line switch. If you get a crash when you create a new Diagram, please us the 2nd shortcut to start Workbench. Software rendering is slow, but currently the only workaround on old machines or VMware images (Parallels supports OpenGL).
If you are on Linux or OS X you might ask why we have decided to first release on the Windows platform. And why the releases for Linux and OS X will happen a few months later. Here is why.
We believe we can deliver better quality if we focus on one platform first. By having the whole team focusing on one platform we can get a release out sooner than it would be possible by supporting all three platforms from the beginning.
And the sooner we release, the earlier we get bug reports. And this benefits the quality. When we are going to release on the other platforms the back-end code will already be well community-tested. And even the first releases on Linux and OS X will have a decent quality.
But why did we choose Windows as the first platform? Actually, it was not us – it was you, our users. Looking at the bug reports we got for the old GUI tools it is clear that 90% of the reports are for Windows. And that made the choice easy.
The question remains why we do not use Java or a cross platform GUI toolkit. The answer for that is that a lot of developers do not want Java to be installed on their development machine. I personally love Java as a language but I can see their point, so that was not an option. For the cross platform GUI toolkits – we have tried a number of them. But non of them really delivered what we needed.
So I hope our fellow Linux and OS X users (I’m on OS X now as well) will understand our motivation behind this decision and will be even more happy when they are going to try Workbench on their platform and find it working very well.