Ann W. Harrison wrote:
> James Day wrote:
>>
>> From a Support perspective we want one rarely incrementing integer
>> to look at that is changed only when the internal format changes in a
>> way that causes a tablespace built with one version to be
>> incompatible with previous versions. Our version problem is mostly
>> telling customers how far back and forward they can go without having
>> to back up and reload their data.
>
> In other times and places, the version number had a major and a minor
> part. The major part indicates an incompatible change. The minor
> part indicates a compatible change - though in some cases compatibility
> is in one direction. For example, a 6.7 engine can access tablespaces
> with a version 6.0 and greater, but a 6.5 engine can't access 6.6
> tablespaces.
>>
>> We also need to be told the versions in which this changes (as does
>> the Documentation team) so we can track what is and isn't compatible.
>
> Under that format, you have to backup and reload to go backward across
> minor versions (revert from 6.6 to 6.5), but can go forward without
> reloading within a major version.
>
The point isn't to identify major or minor versions, but to get a sense
of database history. The build number (in binary) is sufficient for
that purpose. No run time decisions should ever be made on build
number. That is what the ODS major and minor versions and the serial
log version numbers are for.
