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
> 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.