Kevin,
> Jim only mentioned using this version for identification. You are
> talking about upgrades, but we don't have any of those. If we did have
> an automatic upgrade of the data or format in a tablespace, then we
> would need something to compare with to know if it can be done. Once an
> upgrade is done on a tablespace, the ODS version numbers should change
> as well.
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.
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.
If you don't have a test that blocks starting with an incompatible
tablespace version yet it would be good to add one, because customers are
certain to try mixing arbitrary versions.
Anything else that goes in there is fine and may be helpful, so long as
there's that seldom-changing "backwards compatibility is broken" indicator.
James Day, MySQL Senior Support Engineer, Sun Microsystems, England
