I found several closed threads on this issue. However, I want to re-open the discussion, because NONE of the answers were reasonable nor adequate. A rapid release cycle does not necessitate the major version increment - in fact, the versioning scheme is made up anyhow and completely arbitrary, and up to you. Instead, much of the software industry has shifted to a year-based revision scheme, that way people instantly know how old their release is. Why not do that? Cal it version 2012.x for rapid release cycles, that way you can release x every so many weeks. And, 6 weeks is way too fast. I saw this in the CAD/CAM industry, where vendors released patches every 6 weeks. You know what ended up happening? Customers just collected the CD's that were shipped on a shelf collecting dust, and never installed the patches because they disrupted users, caused compatibility issues, and system outages. Nowadays we are bombarded with a whole slew of software update messages - Windows Update, Ubuntu Update Manager, OS X Software Update, and on top of that each app may have its own update mechanism - often I get several update prompts a day!! This is the single most annoying thing (as a 35-year professional in the industry) in today's computing environment. Let's get a little dose of reality here - first of all, OS vendors are now providing conduits for software updates, use them! Second, do we really need updates that often? Why don't you categorize and prioritize the updates? Categorize them like: Core Feature, Security, Cosmetic Feature, Performance, etc. Prioritize them like Critical, Urgent, Medium, and Low. Then let users pick which feature categories and priorities for each category we want to be notified of, like this: NOTIFICATION: (list categories and allow us to select priority - also allow no notification) UPDATE: (same) Where Notification gives us the chance to pick whether or not to incorporate the update, and Update performs it anyhow.