> he said many times he will do his best (which is quite a bit,
> fortunately) to support both.
> I hope this will not require forking IBO itself at some point.

The worst it will impose is a driver layer. I will NOT fork IBO into two
separate source trees to support the two database versions. I have my eye on
DB2 and native client dataset midware support as well so I look forward for
the occasion to shake things up a bit there. I am only missing two pieces of
major technology and some re-org to pull this off. Oh ya, time is a factor
as well. <g>

The occasions I do fork are for other reasons like when I am doing what I
did between IBO 3.6 and IBO 4.0. I forked so that I could continue to
solidify 3.6 and move forward rapidly with all of my prototyped feature
enhancements (which were forked at an earlier time and then scrapped in
favor of starting from a clean base again).

I am about to fork off again and continue the 4.2 version as the stable
solution for Delphi 3, 4 and 5 and CPPB counterparts. The reason I am
forking (branching would be a better term) a new branch is so that I can
take care of the Kylix port from a clean base. I've already had a Kylix fork
from the past but it is going to get scrapped and start fresh again taking
everything learned from the first go around.

I know this might irritate a lot of people that I am delayed by this but I'd
rather be right than be first. IBO 4 was a very significant step forward in
functionality and I want the core totally solidified before I start getting
the waters muddied up with other major programming tasks. I also wanted to
get the bulk of this version clean and tidy before forking off because it is
terribly difficult to maintain multiple code bases when one of them is
significantly changed.

If anyone feels to argue against this I am happy to receive your criticism.

Here's what to look for in the future.

IBO 4.5 will be for LINUX support.
IBO 5.0 will be the multi-database driver capability.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com