Jason Dodson wrote:

>While that tends to be true with minor versions of software (I would
>expect that... say... firebird 1.5 is compatible with firebird 1.0.1), a
>major version jump is just that... a new version of software.
>
>The Apache people have a 1.3.* and a 2.0.* branch of their software,
>neither compatible with one another. Unfortunately for this example,
>1.3.* is still maintained, but that wasn't the original intention. The
>problem ended up being that a lot of module vendors were simply refusing
>to port their modules to the version 2 platform, or they have left the
>face of the earth.
>
>
>

I like to think that we have a more responsible perspective on backwards
compatibility than Apache. I can't speak for other developers, but I
absolutely despise having to maintain both 1.3 and 2.0 modules
(particularly since the differences are arbitrary and capricious) as
well as three separate binaries for different base levels of 2.0. I'd
go so far as to say that the only really good thing about Apache is that
we can learn from their mistakes.

The goal from the begining of DSRI (DEC Standard Relation Interface) and
it's close cousin OSRI (Open System Relation Interface) is to support
multiple implementations with full forward and backward
compatibilities. And, to a surprisingly large degree, it has been
successful. If I were to dig an ancient VAX out of my attic and port
the original Interbase gateways to modern machines, VAX Datatrieve V2
running on a 1984 version of VMS would be able to connect to a Firebird
2.0 or Vulcan database. Less sure, but I'd bet even money that QLI
could open a (now Oracle) Rdb/VMS database.

The keys to forward and backward compatibility is to plan for change and
to anticipate that change won't necessarily be what you expect. Almost
everything within OSRI is tagged with a version number -- protocol
version, blr version, ODS version, dyn version, etc. Each version is
designed for internal extensibility, but if all else fails, the version
can be bumped and the rules change. This allows us great freedom to do
rolling upgrade, supporting the old while implementing the new.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376