Right now at Flex we're gearing up for the release of 4.4.27, which is a critical maintenance release addressing bugs and some of Flex's more annoying quirks like package or kit substitution.
Most current users of Flex are either running 4.4.21 or 4.4.23. You may have noticed we're skipping ahead to 4.4.27, so what happened to 4.4.24, 4.4.25, and 4.4.26?
First, we've made some modifications to our release automation tools and some of those release numbers were scratch releases done to test those tools. In other cases, specifically 4.4.24, that release was not cleared by QA for deployment. In the wake of 4.4.23, we'd made our release process a bit more formal. Every release has to go through regression testing before deployment and that regression testing has to be exactly what will be deployed, not the latest from the source trunk - this means a tagged version of Flex, not a snapshot. We used to build a release after QA gave the thumbs up. Now we do it before. This means that QA may reject a tagged version of Flex and that version never gets deployed.
The software developers among you may be asking yourself at this point "Why don't you just use release candidates?" The answer is we'd love to, but we need some better tools first.
Because Flex has so many modules and our release process involves a dozen or so separate source packages, we don't have an easy way of retagging a release candidate as a release -- yet. So, when we produce a release candidate for QA, it gets a real version number and if QA doesn't give the thumbs up, we burn that version number. Ideally, we'd submit version 4.4.27 to QA as 4.4.27.RC1 (RC stands for release candidate). If QA blesses the release, we'd then press a button and retag and rebuild RC1 as 4.4.27.
Right now we'd have to do this manually for a large number of source modules. It would be time consuming and introduce the risk of human error. We built a recursive release plugin for Maven some time ago and that's what we currently use to perform releases. When we get around to modifying this tool to retag release candidates as GA releases, we'll stop burning version numbers. In the meantime, if you notice that the version numbers skip a few slots, it's a sign that our QA team vetoed a release candidate.