|
Here's a few reasons why developers use normal version numbers to begin with. Many times they use it to give a clearer indication of the types of changes that are in the new version. For instance, a common theme I've seen in a number of projects is a version number such as X.Y.Z.
X represents the major version number of the project. An increase in X indicates a sweeping change to the product. It could range from a complete re-write of the codebase to major features being added/removed. There are no guarantees on compatibility between it and the old version.
Y represents the minor version number of the project. An increase in Y indicates minor, but user-noticeable changes to the product. Generally these are smaller new features and generally nothing is removed. Generally, it's also compatible with older versions.
Z represents the revision number of the project. An increase in Z usually indicates bug fixes or code changes that don't change the usability of the product. You're pretty much guaranteed compatibility with older versions.
Again, this is only an example. Some places have versioning schemes much more complicated. Some are completely arbitrary. It all depends on the type of product and how important versioning is to the development cycle.
Simply using a date as a version number may add information you'd like to a product, but for most cases the release date is irrelevent because users simply want the latest version. You also lose the original information your versioning scheme might have provided.
|