Explain version system?

We don't use alpha and beta. Those are sometimes used by the the base apps. We use Pre-Release and Development Test so that we don't confuse our versions with the alpha, beta and release candidate labels used for the base app.

A development test is used first, and is the initial builds of our portable packages of an app. A dev test is essentially considered an alpha or early beta quality release and uses the PortableApps.com Development Test splash screen.

A pre-release is used next after a package has been tested and we've worked out the kinks and it has been reviewed. It gets its own custom splash screen. And this is the step before it is done for official release. In terms of other software, a pre-release is essentially a release candidate and if it passes muster, it will be called a final release after testing.

Once an app is officially released, if we do a test release of the next version, we call it a pre-release as nothing major is changing in our code.

The numbers after the word Pre-Release or Development Test is basically which test release it is. So, if we're portablizing Acme 2.4, a developer would post an initial release as Acme Portable 2.4 Development Test 1. He'd get feedback from others, fix issues in the launcher and PortableApps.com Format and then it would be released as a new package called Acme Portable 2.4 Development Test 2. If that package was solid and the release team tests it out, it is approved to move up to a pre-release. A splash is made for it and the next package is called Acme Portable 2.4 Pre-Release 1. More people will test out a pre-release. If it has some issues and requires another release, it would be Acme Portable 2.4 Pre-Release 2. If, on the other hand, it works and is ready for release, it is repackaged, digitally signed and becomes Acme Portable 2.4.

The four digit release numbers are used mostly for internal stuff. The PortableApps.com Updater needs them to be higher for each successive release. In the above scenario, we might use 2.3.99.1 for the first development test and then increment the last digit for each successive release. The final official release would be 2.4.0.0.

Lastly, we have revisions. These are used when we are fixing a bug purely on our side or updating our launcher or installer with new features between app versions. Since the base app version hasn't changed, we don't alter it. So, say we released Acme Portable 2.4 (with an internal version of 2.4.0.0) and a few months after its release, we've come up with some new features for the launcher that add new functionality and a new version of the PortableApps.com Installer with new features or updated localizations... but we know Acme 2.5 isn't gonna come out for a while so we don't want users having to wait to get the bug fixes or new features. We'd do a new release of 2.4 and call it Acme Portable 2.4 Revision 2. The internal version would be updated to 2.4.0.2 so the PortableApps.com Updater see that a new one is available.

One final note on the versions, most app use 2 or at most 3 digits for version numbers. This is what you're supposed to do as the 4th digit is generally for internal build versioning. The exception has been Firefox and Thunderbird (though with Firefox 3, Mozilla has finally ditched the 4th digit and is using the 3rd digits for bug fix updates as they're supposed to). So, Thunderbird's current release is 2.0.0.21. But we call it 2.0.0.210 internally. This is so it can handle revisions. A revision to 2.0.0.21 would be versioned as 2.0.0.212 internally (so it works with the updater) and when 2.0.0.22 comes out, it will be versioned as 2.0.0.220 internally so the updater is still happy.

It's a bit complicated to look at it all quickly, but ultimately, it was the most elegant solution to the whole problem.