At 11:44 AM 5/1/00 -0700, David Schnepper wrote:

>
>
>There's 4 upgrade paths:
>- No change necessary.
>- Automatic conversion made first time new engine touches a file
>- A utility program to perform file conversion, specifically invoked
> by user.
>- Complete backup / restore
>
>For V5 ---> V6, all methods were discussed, and compared to resources
>available, risk, etc. Complete backup / restore was selected.
>
>There are 4 downgrade paths:
>
>As I recall the code (aside: one of these days I'll be able to look
>before speaking) -- an engine only looks at the Major ODS to decide if
>it can access the file. It looks at the Minor ODS to decide if there
>are any Minor ODS updates it should apply to the file.
>
>InterBase automatically makes any Minor ODS updates the first time a file
>is opened. These are safe, backwards compatible changes.
>

Thanks for the history. You were there; I wasn't.

The meaning of the ODS minor version has apparently drifted over
the years. Originally, the engine required that major version
of the file and engine match and the minor version of the file
be less than or equal to the minor version of the engine. This
strategy permitted upward compatible ODS versions. An example
was sometime in V2 when we added index subtypes to differential
between text fields and variable length binary fields. The
point release created database tables that were not backwards
compatible, but could read databases of either flavor. There
didn't used to be a concept of update-in-place.

I fear you are right about the engine not checking the minor
version number. Had this been in place, it would have been
easier to make a rolling upgrade. I think this is something
in the code that should be fixed ASAP to allow future rolling
upgrades.

I don't believe in downgrade paths. I don't think the engine
should ever make non-backward compatible changes to a database
file. If a user does a proper gbak and restore, the engine
can use new functionality. The reason for this is simple:
We software guys screw up a lot. From time to time, in our
enthusiasm to get the latest and greatest to the hands of the
users, we ship something before its time. When that happens
(and it will), it is critically important that we haven't
damaged things past the point of recovery. This has saved
our butts in the past, and although I hope Interbase will
never ship with a bug in the future, in theory it could happen
(tongue firmly in cheek).

My opinions of software upgrades is similar to my rules for
sailboat navigation lights:

1. There must no no way for water to get in.
2. When water gets it, there must be way for it to drain.
3. It has to work full of water.

Belt and suspenders aren't enough.

Thanks for the history, Dave.

Jim Starkey