Firebird Future Development : What to Expect?

by Dimitry Yemanov, 2005

1. Review of Firebird 2.0

Some time ago, many of our users were surprised by the number of features released in Firebird 1.5. Honestly, before preparing this paper, I didn't count new features in Firebird 2.0 and I don't have a clue whether it's superior to the version 1.5 in this aspect or not. But, in my opinion, the major benefit of the version 2.0 is not its feature set. "What then?", - you ask. I'd describe Firebird 2.0 as "the version which removes the annoying limits". Sounds not so modest, I know. Let me explain better. No doubt that Firebird has a nice multi-generational architecture and a rich SQL language, an embedded usage and a good performance. But I'm sure almost everyone stepped on some internal limitations that worried or even shocked you. To name a few (in no particular order):

Some of them could be of critical priority for your business, others are just annoying. Anyway, I'm glad to report that Firebird 2.0 eliminates most of the aforementioned issues and significantly reduces the impact of others. As for me, this is more important than declaring new language features. But considering also tons of bugfixes and enough new features, Firebird 2.0 definitely represents a major release of your favourite RDBMS. More robust, more feature complete, faster and much more friendly to non-ASCII users.

Of course, there are limits that still exist and many features we don't support yet. But we should have some room for future improvements, shouldn't we? We'll talk about the future development a bit later.

Well, for those who're interested in numbers, let's read the WhatsNew document or Release Notes and make a summary of total changes per version:

Note: the version 2.0 statistics represents its current state, i.e. Beta 1 release.

Impressive, don't you think so? Obviously, Firebird 1.5 was developed longer than Firebird 1.0 and the same appears to be true for Firebird 2.0. But at least you see what the development time is spent for.

2. Roadmap of future versions

Speaking about the short-term plans, our primary goal is to merge two codebases (Firebird 2.0 and Vulcan) in order to release Firebird version 3.0. It will be based on the Vulcan tree and will contain its modular architecture and new features, as well as all improvements made in Firebird 2.0. The key features of the Vulcan codebase are:

As both Firebird 2.0 and Firebird Vulcan releases are going to co-exist in the next year, you may ask why version 3.0 is numbered as a major release and what else (except of features already done in both codebases) it will contain. A good question. As we want to shorten the 3.0 release cycle as much as possible, no completely new development is expected to happen in that version. But we need to keep our users interested, so something new should be introduced. Solution is simple: the 3.0 release is going to incorporate all the work done inside independent branches. As you perhaps know, there are some improvements done by various Firebird developers that didn't go into the 2.0 release due to time constraints. Some of them are included and being tested in Fyracle, others are still in private trees. Also, we still have a few features in Yaffil that requires backporting into Firebird. Everything mentioned above is exactly the new stuff you'll see in version 3.0. Let's see what has been already done:

These features are the major candidates to be included into Firebird 3.0, but there are others (less important) as well.

As soon as version 3.0 will be released for public testing, development of the next version will begin. We don't have a decision about version numbering yet, so it could be 3.5 or 4.0 or whatever else. For the duration of this talk, I'll be calling it "version 3.0+", where the plus sign simply means "the next version". Version 3.0+ is going to have major ODS changes as well as a lot of administration, tracing, security, performance and SQL improvements. Most probably, it will also contain an updated remote protocol implementation. Now it's a bit early to say what exactly will be included in that release, but you'll find some hints a bit later.

If you'd ask me to outline the generic development priorities, they would be:

  1. Reliability and safety (bugfixing, guaranteed recovery, security improvements)
  2. Administration and monitoring facilities
  3. Compliance with the SQL specification
  4. Performance (both algorithmical and optimizer decisions)
  5. Language enhancements

Now a few words about the 2.0 point releases. First, our usual maintenance schedule will definitely cover the 2.0 product line, so please expect 2.0.1, 2.0.2, etc releases (containing bugfixes) every few months. As always, these point versions will consist of changes backported from the active development branch. So, if you see your "favourite" bug fixed in version 3.0, feel free to ask developers about porting it into the next maintenance release of 2.0.x. Second, I'd expect some of the scheduled 3.0 features (e.g. GTT implementation or WITH [RECURSIVE] code) to be ported into the 2.0 HEAD branch before the merge in order to make a 2.1 minor release possible in the case of noticable delay with the 3.0 development.

Recalling everything said above, the timetable should look like:

2005:

2006, 1st quarter:

2006, 2nd quarter:

2006, 3rd quarter:

2006, 4th quarter:

The key point of this roadmap is when we're able to release Firebird 2.0 and Firebird Vulcan. And this is exactly the point where your help with testing/feedback allows us to move faster.

3. What features to expect?

This part of our talk is dedicated to the project activities that we'd expect to see in the not so distant future. To follow the list easily, they're grouped by category, similar to our RFE tracker.

Every work has two associated parameters: priority and complexity. The priority value is based on user wishes, it's set up after looking at various polls and forum/newsgroup discussions. In other words, it shows how much our users want a particular feature. Also, this value depends on our analysis of the features offered by our competitors. The complexity value is based on time/effort estimates made by the core team. "None" means that all the required work is already done (in some code branch) and we just need to backport and test it. "Implementation" means that the feature has already been discussed and agreed on, but it still requires some minor discussions and the actual coding. "Design" means that we have a basic agreement and some vision of the things, but the work hasn't been discussed in depth yet and hence we don't have any implementation plan. "Research" means that the work requires serious analysis before discussing its design and implementation specifications.

Administration / Tracing / Monitoring

Security

Language extentions

Performance / Optimizer

Maintenance / Recovery

Generic / Architecture

Obviously, the aforementioned list is not complete, it includes only the changes that we consider mostly important. If this list misses your favourite wish, speak now!

Now let's create a matrix where most preferrable and easy-to-do features are placed in the top-left corner and most hard-to-implement and/or less wanted ones are in the bottom-right corner. If you'll be moving from one of these corners to another you'll see a most probable feature implementation roadmap. Recalling what has been said before, we could imagine a more detailed roadmap:

Firebird 3.0 (the merged version):

As you can see (and as it has been stated earlier), version 3.0 is expected to include the work already done and a few features that are highly wanted and relatively easy to implement. Everything else tends to slow the development down and hence is excluded from the above list.

Firebird 3.0+ (the next major version):

It would also be excellent to design schemas/namespaces and longer metadata names for 3.0+, but no promises here. The same for external data sources and deferred constraints.

Firebird 3.0++ (something we don't have a schedule for yet):

Of course, some intermediate or minor releases may happen in the meantime, as we'll try to make the release cycles shorter. As soon as the details are discussed and agreed on among the project admins, you'll see both an actual short-term roadmap and an expected long-term roadmap on our site.