George,

> I am concerned about the wider implications - regardless of
> the 'correctness' of syntax used in earlier versions.
>
> It seems each new release, instead of building on previous ones,
> creates new problems in existing, tested and released code.

Bear in mind, the vast majority of recent changes in IBO are to accommodate
new features and capabilities in Firebird version 2. I do my absolute best
to preserve backwards compatibility. In the case of this problem you are
responding to, very few people use parenthesis as Paul does and I will
support this with a fix. Less than 1% of my users are likely going to be
affected by this and I'll probably have a fix in terms of days rather than
months. The reason this problem appears is due to how parenthesis are used
with the new derived tables feature of Firebird 2 and my lack of mindfulness
about how some people would use parenthesis for other reasons when
implementing derived tables. I was not entirely ignorant of this use of
parenthesis either, I just wasn't mindfull of it when I needed to be.

> We have evaluated IBObjects and are seriously considering
> incorporating it into our products but we are very concerned about
> configuration control and backward compatibility. From messages in
> this forum, upgrading seems a somewhat risky business, especially if
> considering migrating to Firebird 2.0 from 1.5.

Migrating from FB 1.5 to FB 2.0 is going to have challenges regardless of
the toolset that you use.

> Clients / Users know nothing of IBObjects, (nor should they). All
> they will see is an application that used to work that now has
> problems after a routine maintenance upgrade.

It is unreasonable to expect a working production application built for FB
1.5 to work against FB 2.0 without some iterative redevelopment and
thoroughal testing given the number of significant differences between the
two and given the Firebird development teams focus on correctness and
compliance more than backwards compatibility.

> This will reflect badly on us.

Only if you overstate the capabilities of Firebird and then fail to QA a new
production release.

> The only way to avoid these client problems will be to revisit
> all old test scripts from scratch, adding to the admin overhead and
> associated costs. There is also no telling what impact there may be
> on user support documentation.

These are real costs and real impacts. Your point is very valid.

However, these things are standard procedure in every software shop I've
ever had employment at. With any new release of a product which is part of
an interdependant group of tools, testing and user impact should be a top
priority prior to any production release.

It took me quite a bit longer (3 months or so) to make IBO work exceedingly
well with Firebird 2 and I could complain about it but rather I see Firebird
becomming a much better product overall and it has forced IBO to also become
a much better product overall. I had to pass some of this work on to my
customers but I am certain those who fully understand the need for true
progress in information technology and simply take it head-on; their
products will also be much better overall as well. It's just a reality in
our industry that we need to be as responsible and responsive as possible to
a fast changing/evolving development environment. The ideals you seek are
money and management savers but they would be very expensive in terms of the
progress they would hamper.

> It is a problem for us and we will monitor the situation before
> making a final decision.
>
> I would welcome any comments or assurances in this area.

Hopefully what I've shared gives you an idea of our philosophy and our
commitment to balance these two aspects as best we can.

Regards,
Jason Wharton