With the great help we receive from community and SE Beta testers we are marching towards RC quality with large steps. This week we hope to remove the last obstacles (mostly printing, some canvas problems and some synchronization problems) that are holding us back and to be able to close all open P1 & P2 bugs. If we achieve all this we will upload the RC1 (Release Candidate 1) build.
As a bonus we have now added the much requested “direct connection” notation between columns (better know as MS Access style notation) to the Standard Edition – a feature that has been requested since the old DBDesigner4 days. Personally, I am not so found of this notation because it limits the connection points to the left and right of the individual PK- and FK-columns which makes it harder to have a nice looking model. But given the flexibility of Workbench to hold an unlimited number of smaller diagrams this might solve this problem for most I hope.
There are a lot of really good feature requests that have been filed and I am sad that all that are now open will not make it into the WB 5.0 release. But we had to stop at some point and focus on quality. We will try to incorporate as many as possible into the WB 5.1 release that should happen later this year. So please do not stop to share your ideas on how to improve Workbench and file feature requests in the bug system – we are always listening.
I will blog about the process of the RC build during the week. Stay tuned!
We are about to release the next Beta version of MySQL Workbench. There are no new additions like in the last release. This will strictly be a bug-fix build. Apart from several smaller fixes this build will see an improved software rendering performance. Alfredo has blogged about the changes in his last post. And the changes are really paying off. Tax tested it on several machines and found the speed to be acceptable even on older machines.
The slow and flickering software rendering has been one of the major points of complain (except from the yet missing Linux and OS X versions that will be released later this year). Now that this is out of the way we are marching towards the RC level, fast.
If there are no new obstacles the release build will happen later today. Markus from the web team will get online on Saturday or early Sunday to update the download pages. Then we will send out the announce emails asap.
From time to time it is necessary to get a bigger picture of your project in terms of size, test coverage, code vs. comments ratio and others (aka metrics). While it is quite difficult to find a good (and free) code coverage tool for C++ there is already a very nice tool package called DPack, which is not only freely available but also gives us some very useful additions in our IDE. One of those features is code statistics.
Continue reading “Tell me what your code looks like…”
We are working hard on the next Workbench Beta release that should be out mid next week. It will include a list of top priority bug fixes as usual but also two new additions that have been requested by our beta testers.
The new Online Update menu item allows to update your current installation to the latest available release right from within the tool. No need manually browse web pages anymore – at least if you are using the MSI based packages. The reason we are not offering this for the zip packages is that an automatic update is tricky since you might have made a custom install based on your needs. If you are using the zip packages you can keep using the normal Version Check menu item that will inform you about the version you have installed and if a new release is available.
The second addition is a better reporting after schema diffs. We added the templating engine (thanks Google for ctemplate!) we also use for the normal schema reporting feature and are now able to list the actual schema differences in plain text. The tree view is still available but for everybody who would rather read through the differences than browse the tree this feature will come in handy.
The Lua plugin support has been finally fixed and will be working in the next release. Together with a few other improvements, it’s now possible to write your own commands to do all kinds of tasks. Documentation for the plugin system is not yet written (and the previous one is outdated), but it should be straightforward to copy the supplied Lua plugin and change it to do something else. All you need is to know a little Lua (which is a simple scripting language) and explore Workbench internals using the GRT Shell (View -> Advanced -> GRT Shell).The sample Lua plugin is located in the modules folder. You can copy it to the custom plugins folder which is shown in the GRT Shell at startup and change things like the module name and add your own functions. I’ll write more about how to write such functions in a future post, like after the next WB is actually released.There are a few ways that plugins can be accessed, including just calling them from the GRT Shell, from the main menus (which you can change in the main_menu.xml file or in a menu editor when its written) or from context menus for the objects that the plugin supports. In fact, most functionality of Workbench works the same way as plugins, so there’s a lot that can be done.
Apart from more than 60 bug fixes the upcoming MySQL Workbench 5.0.11 release will contain a few major improvements in respect to the last release two weeks ago.
- The partitioning settings are now fully supported during reverse engineering of SQL scripts and live database and CREATE / ALTER generation for synchronizations. We had a preliminary implementation but this has been replaced by full parser support.
- Addition of Standard Insert grid input. Instead of having to type in the full INSERT statements the initial/test data can now be entered by using a data grid.
- Improved formatting of generated SQL output.
- Improved GRT Shell console. This is in preparation of the upcoming tutorials on the scripting- and plugin writing possibilities
The show-stopper bug that is holding back the release is now fixed. We will run detailed tests tomorrow and if nothing else comes up will upload to the mirrors then. Standard Edition Beta Testers will get an email notifying them about the new download addresses.
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.
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 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.