Back in the early days in ZPE I released tons of new versions almost weekly sometimes but often monthly. I suppose this release cycle was down to the fact that it was under a big development - things have slowed since.
But back then versions had multiple build versions (if we follow the ProductVersion.Major.Minor.Build pattern) Version 1.3.5 was the most obvious example (that's ProductVersion 1, Major version 3, Minor version 5) because it had 1.3.5.32, 1.3.5.60, 1.3.5.68, 1.3.5.90, 1.3.5.190. Why so many versions?
I believe 1.3.5.60 was one of the most significant upgrades to ZPE in it's history. That's because it added Real Math Mode, which is now part of what is called LAMP (Logical And Mathematical Parser) which allowed mathematical expressions such as 5 +5 to be evaluated straight from the interpreter. It was a huge improvement. In my new system, this huge upgrade would likely have sanctioned a new Minor version (so in this case, it would have become 1.3.6.0) but back then my versioning was based on the number of compilations I made.
So why was this?
Well, back then a new Minor version came along when I had asked my testers to fully test the features of the previous version and assure that they work as expected. This way, a version with a Build of 0 was a stable version (or as stable as testing can assure). Nowadays, this is not the case. Versions are released when I feel that enough has changed to sanction the new version. I no longer keep the compiled version at the end of the version as the Build version unless something is fixed (but no new features are added as this would be a new Minor version).
New versions are now mostly released when something that worked before will no longer work in the new version. For example, the ZPE Standard Library is a bunch of ZPE based functionalities and is compiled prior to use. This means if any of the byte-codes are changed in YASS the whole library needs recompiled. This is why this indicates the need for a new version number.
