This is not a Madden game, nobody is asking for yearly updates for Visual Studio.
If your employer is to slow to keep updated, why should that slow MSFT down for you while the it is trying to reinvent itself, just catch up in 2015.
Just because it's trendy to bash MS for not releasing new browsers/IDEs/whatever every few weeks, that doesn't mean the vocal critics speak for all of us, nor even necessarily for the majority. I get paid to build stuff that works, and doing so requires stable foundations and reliable tools. Lately, I wish we had more Microsofts in the world paying attention to things like backward compatibility and long-term support, and fewer Googles and Mozillas and Apples who are quite happy to push out updates that break useful things that worked before.
There was nothing wrong with releasing a major version when you had major new features, more frequent minor versions that introduced minor features in a compatible way, and point releases for urgent security issues or bug fixes that didn't change any intended behaviour at all. This approach has worked for a long time, and IMNSHO the recent regular, fixed schedules for updates regardless of actual changes aren't doing most people any favours, and the version-free, always-online, push-updates-whenever stuff is just a mess that causes far more trouble than it's worth.
Did you mean forward compatibility?
No, I really did mean backward compatibility. Specifically, I was thinking of the degree to which MS have supported even very old (by IT standards) APIs and file formats and protocols even in much newer (again by IT standards) systems over the years, and the lengths they have sometimes gone to in order to maintain that support despite the potentially breaking changes not even being their fault in many cases.
However, I would also agree that they are better at forward compatibility than a lot of other major software developers today.
So here is one reason. Another one - is money - why spend every (or two) years money on product that is not bringing that much to the table (for a lot of projects at least I've been)
Ahem... I am. I would much rather have smaller more frequent updates to important tools than huge disruptive ones. Short feedback loops are a good thing.
I agree with you but a Service Pack should suffice esp. right after you've release a full new version/update to a major product/tool like VS.
I'm pretty sure I can upgrade to a service pack. Changing versions, OTOH, probably requires approval from management.
Two things are apparent: 1) The problem you are addressing is a management problem in your organization, not a problem with Microsoft releasing a new version of VS. 2) You aren't the decision-making customer for Microsoft VS at your organization, so even the problem you had was with VS, it wouldn't necessarily be a problem MS would have much incentive to address.
That's what service packs are for. With a product that has as big a footprint as Visual Studio it will be impossible for shops to keep up with the annual versions. Many will simply delay updates. Ironically, increasing the speed of major release may actually delay the introduction of some improvements by customers.
I'm actually running 2012 personally, not such a big deal on that front, my side projects tend to be pretty manageable and not hugely large or sophisticated.
But yeah, you have anything large and enterprise-y, the pain just amplifies each version you are behind.
Nevertheless I have read some worries that some bug fixes (may) break backward compatibility and therefore projects targeting version 4.0 developed on machines with version 4.5 installed may behave differently when run on machines with only version 4.0 installed. If this is a real problem, that is if there are observable changes and therefore version 4.5 is not fully backward compatible to version 4.0, I can not tell.
UPDATE: There is a published list of breaking changes [1].
It wasn't that much of a problem. It took about 3 days and most of that was fixing deprecation warnings and porting the in house test framework to NUnit.
The real problem in the process was getting the build tooling and all the associated crap surrounding the solution up and running. This was also only because the muppets who wrote it originally put it together with sticky tape and string.
Maybe Microsoft is tight on money. :)
Sadly it seems to be the way it is going. Most likely driven by Windows 8.1.