I'm furious that you have decided to dictate to the developer what format their versioning scheme must match? Our versioning schemes have been the date of the revision for the last 11 years, (the last ~3 years being inclusive of Adobe AIR), e.g., today being 20120206. It has suited our needs perfectly. It -also- allows file names to be ordered correctly by filesystems.... what a nice bonus. It makes sense for our development/distribution model. It makes -far- more sense for non-tech-savvy end-users.
Did I mention that they are non-tech-savvy? You've switched horses midstream and destroyed the automatic update chain for our application with no backwards-compatability that I can -easily- find. (I shouldn't have to... get your totalitarian ideals out of my version number).
It is imperative that our distribution model be as simple as possible for our end-users; educators and parents and facilitators for pre-literate developmentally and behaviorally disabled children, to access and use. Now they must uninstall (if they even have administrative rights in an educational institution without troubling their school tech administrators) the existing software, and install the new.
This is extraordinarily poor policy. Your -PRIMARY- concern should be preservation of the update structure of applications developed/distributed using the Adobe AIR technology. If you break that, you torpedo a major element of what makes AIR a feasible and attractive option.
Your policy won't even permit 2012.02.06. Why? Why arbitrarily decide 0-999? How hard is it to add simple parsing code to match previous version formatting to updated version formatting and determine if it's a later or earlier revision. Mine passes a simple test; isInt() ? (New > Old ? Newer : Older) : move on to more complicated parsing.
