Tracking Changes - Mastering phpMyAdmin 3.4 for Effective MySQL Management - page 306

If we apply this principle to database development, the decision that a table is ripe
for a new version should be made by the development team when a significant
change is about to occur on this table. How significant the change has to be in order
to trigger a new version is a matter of interpretation within the team. At least one of
these decisions is easy to make: version 1 always represents the moment where we
first switch on the tracking for a particular table.
In the situation where data manipulation statements are tracked, we should note also
that the change can be relative to data itself, not necessarily to the structure.
phpMyAdmin's tracking system uses only positive integers as version
numbers; it's not possible to use a decimal point as in "1.1".
Taking a snapshot of the current structure
Every time we create a new version, the tracking system takes a snapshot of the
current structure and indexes of the table, and creates a new entry in the tracking
system. In this entry are stored the database name, table name, version number, date
of creation, and the complete structure information.
This tracking snapshot does not contain a table's data! Therefore,
the tracking system does not replace a backup system.
During the lifespan of this table after the snapshot has been taken, all tracked
statements are stored alongside this snapshot. Therefore, a table tracking version
consists of the snapshot in addition to all of the changes made after this snapshot
was taken, until a new version is started.
Understanding archiving issues
When a table is dropped, its tracking information survives, unless we decide
to suppress it. The impact of this will be discussed later in the Deleting tracking
information section.