The Linux kernel release history, on a minor version odd/even unstable/stable cycle for years, got stuck breaking interfaces and developing major features within 2.6.x point releases for 7 years before inexplicably jumping from 2.6.39 to 3.0 to 3.1 in a period of weeks with little explanation. Indications of arbitrariness at high levels of an organization suggest dysfunctionality elsewhere.
Version numbers are actionable data which provides users with a choice. The magnitude of change between the current and new version communicates approximate risk/reward. I know that if I install a new major version that it could potentially break stuff, but it's my decision to make and since I am involved in the change I can schedule it to minimize risk to myself and my customers and I know to be on the lookout for problems.
Removing this option means my software might break at any time and I can do nothing to stop it. Furthermore, if something does go wrong, what can I do about it? I won't even know whether the problem was actually caused by an update or not since I won't know if an update has happened at all. And if an update does cause a problem, what can I say or do about it? "Today Firefox started acting strangely." I don't know what version it's on or how to get updates so I can't roll back and I can't schedule upgrades to minimize risk, so my browser might crash or freeze in the middle of a product demo for all I know.
This tends to happen whenever a system supports that supports a lot of external code such as hardware and operating systems, but can bite libraries and plugin-supporting applications as well. Just such a problem has bitten Intel's x86 chip and Microsoft Windows NT, resulting, eventually in the x86's CPUID instruction.