Using version numbers is something we are familiar with; for example, this book describes phpMyAdmin version 3.4.x. However, at this point we must understand exactly why we use version numbers.

A good reference on software versioning is located in Wikipedia at http://en.wikipedia.org/wiki/Software_versioning. This article mentions that version names can be used, but version numbers are more common. More importantly, it states that version numbers "correspond to new developments in the software".

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.

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.

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.

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.