GDA Starts Beta Stage

GDA 6.0 Beta has been Released. Valgrind tests and memory leak fixes are in progress.

To reach Beta stage, some providers and tools, like GTK widgets, has been cataloged as experimental and disable by default.

Now we start a Beta stage, where translation continue and release notes is a work in progress.

Please test it. Thanks to all contributions, translators and reporters. Report any issue you find, thanks in advance.

GDA and disable old stuff

After hundred of commits, GDA is getting fixes for most of its bugs around SQLite, PostgreSQL and MySQL providers. Lot of modernization work has been landing in master, making GCC more and more happy avoiding warnings, some of them are present, yet.

To have a warning free release, GDA needs to modify some internals, hope they are not too invasive in order to avoid bugs.

Internals in GDA is a long history, started in January 2002, evolving and implementing stuff not available in GLib or GObject at that time. But the things have changed and now we have modern techniques to implement interfaces and objects, so a modernization was started since I took the maintainership.

GDA has lot of tools, like entire applications and command line (a la psql), allowing you  to access your data. The one I use the most is its GObject Introspection bindings through Python, to extract, manipulate and push to or from different databases providers; this was the main task on modernization: change the API to be more binding friendly, specially on GObject Introspection; I think it is in a better shape now.

Unfortunately, most tools are buggy, like GTK widgets and so its derived GUI tools, in a level that is difficult to fix with the limited resources we have; this is true for some providers, because they are outdated. This is the reason we have put them in the “experimental zone“, to reduce the burden.

The advantage is that putting things aside, will help to push 6.0 out to the streets in a more short time.

For 6.0, we need to think about if we will keep current API and a very difficult way to implement new in-tree providers; or we take a big step forward and create interfaces you allow out-of-tree plugins. But that will be a different post.