Slalom wrote:

> That's an excellent question. I don't understand it either.
>
> Why are developers fixing V 2.0.5 if there is a V 2.1.1 released and
> stable?. I can't understand.

There are so many reasons. Here are some of the top of my head:

If you have, say 200.000 installations and you made sure your
500k-lines-of-code application works stable with Firebird 2.0, you would
need *a lot* of time to test everything with 2.1 (even if you have a
good unit-test suite, some new problems are always waiting to be
discovered) and deploy that to a large number of customers.

Some customers might even run queries on their own, so they will look
for support in you, not at firebird-support or something like that and
that could be too much to handle. Deploying new version of Firebird is
easy, but you might need provide rebuilt versions of applications as
well. For example, I'm migrating some clients now from 2.0 to 2.1 and I
have to rebuild all of my C++ applications (because they linked to
fbclient version 2.0) and also the interbase.so driver for my PHP
applications. Generally, I can range from being a major PITA to a real
nightmare (if you were not prepared for it).

Also, your customer might run some other software that runs Firebird 2.0
and does not want to upgrade (or developers of that other software don't
want to upgrade to 2.1 because 2.0 'works just fine').

Some software might also need to go through certification process each
time you change it and that might cost a lot of money.

Firebird 2.1 is not completely backward compatible to 2.0. The reason is
that some bugs get fixed and some queries that used to work won't work
anymore. For example, I learned this the hard way yesterday as one of my
queries that had COALESCE(somecolumn, 0) stopped working because I did
not GROUP BY somecolumn. It did work properly before simply because this
column was NULL in all databases (it was reserved for future usage).

Etc, etc, etc.

--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com