At 01:30 AM 31/03/2005 +0000, you wrote:

>Hi All,
>
>My company develops and markets a Delphi application, which currently
>uses IB6 at the back end.
>
>We've made the decision to jump (step) from IB6 to Firebird because of
>the age of IB6, assorted platform issues with it and because of the
>lightweight security.
>
>However the potentially short turnaround between Firebird V2 and V3
>has created an issue for us.

It hasn't created an issue for anyone yet. Firebird V2 is currently in
early alpha testing; V3 is a Holy Grail that will be emerge at some point
in the future when everyone works out direction.

If you are making assumptions based on the wild ballpark times we were
talking about in the draft Roadmap a year ago (still draft) then forget
it. Firebird gets absolutely no propulsion from deadlines of any
sort. You'll regret it if you try to market it that way.

>In short, we don't want to commit to V2, and then find that it's
>orphaned by V3.

Don't understand "orphaned by". Can you explain what you mean?

>At the same time we aren't that comfortable about
>committing to V3 and running the risk that the release date slips so
>much that it's no longer useful for our project.

Nobody should "commit to V3" now. We don't even have a V2 release. If
"release dates" are important in your plans, then my advice is you are on
the wrong track - totally.

>Understand that we have 4000 remote installations of IB6 to convert,
>so the cost of preparing an installation routine and deploying is
>significant.

Sure. And you should not founder in your resolve to get rid of IB 6. It
is unfinished software, released without QA, full of bugs that are long
gone in both release of Firebird (1 and 1.5). Running 4000 installations
of beta software for four or five years must have been fairly exciting.

>There's also the issue of having to deal with concurrency issues
>between IB6 and Firebird. (Mitigated in V3.0 I know, but when?)

Can you describe these "concurrency issues"? And, having described them,
could you then go on to explain how the non-existent V3.0 "mitigates" them?

>At the moment we are tending towards committing to V2 now, and
>assessing V3 in Q3 05.

Umm, I very much doubt that (and I should know....) Wouldn't the sensible,
safe, practical thing be to commit to 1.5 now? That *is* a stable release
with an established support network. V2, on the other hand, is alpha
software, at the stage of being beaten to a pulp by a demonic crowd of
field-testers. Support issues for V.2 are right off-topic until the release.

>Do you think this is this a practical approach?

Nope.

>What will become of V2.0 if V3.0 is an early success?

It's not a valid question. V.3 will be V.2, only more and better; just as
V.2 will be V.1.5, only more and better and v.1.5 was v.1.0, only more and
better. The releases are a continuum. You just move your Firebird
databases along with your more and better Firebird servers, if and when you
want to. Some don't even do that. A new release doesn't turn the world on
its axis. We're talking about continuing as before - with some very likely
cleanup of client code called for - and taking in new features along the
way, according to requirements. No "Leap of Faith" to be seen anywhere.

>How can I obtain some reassurance that recommending Firebird V2 won't
>affect my future "employability"?

If it were me, I'd have the development and QA systems already up and
running (like, yesterday!) on Firebird 1.5, over real-world test databases,
and getting reassurance for myself and others that it's as good as I need
it to be. That's the place from which you should be conjecturing about
future releases that don't exist yet. I don't know what aspects of your
"employability" are at risk by recommending a long-overdue upgrade from
poor, tottery old beta IB 6. However, since you asked the question, I
wouldn't like to be in your shoes if the quality of your research so far
into the facts and issues is a factor in keeping you employed.

./hb