Request for Comments: Issues with .NET and Microsoft Product Versioning
Sponsored By
NOTE: I have had this blog post sitting in my drafts for a few months now. I've gotten close to posting it, held back, then gotten close to posting again. Today I noticed that Microsoft published a patch/update to Entity Framework 4.1 (Code First), a product I personally love and support, and they've called it EF 4.1 Update 1. Then I decide to post this. This is not intended as a rant or a complaint, although there is frustration on my part. What I want to know from you, is DO YOU CARE. If you do, then I can make sure your voice is heard. If you don't care, that's cool too.
I really care about how products are versioned and I'm sure you to do, Dear Reader. Naming Things is Step 0 when it comes to understanding Things. I want to talk to you about some things I've noticed around .NET versioning, and see what your thoughts are so that I might share them with TPTB (The Powers That Be).
I noticed recently that Microsoft released something called ".NET 4.0 Platform Update 1." This is an update to the .NET Framework 4 to include new features and functionality around Workflow and Azure. This post isn't specific to this update, but ALL the updates lately, from the .NET Framework, the Entity Framework, SQL Server, and a dozen more.
This was concerning to me for a few reasons. First, Platform Update "1" implies a future Platform Update "N+1." Second, when something that is a platform called 4.0 is updated, you'd expect it to be called 4.1 or maybe 4.0.1.
I've met with that team, and encouraged them to stick with Semantic Versioning and call these updates .NET 4.0.2, etc. I think they hear me, we shall see.The .NET Framework Team agrees and they've said that will be following Major.Minor.Revision now so the next small release will be 4.0.2! However I may be perceived as Chicken Little as I haven't personally collected broad community opinion.
If you get the Premium version of Visual Studio, you've got a higher SKU than the Professional version. However, if you choose between Premium and Profession versions of Windows 7, get Professional. It's higher.
I recently noticed other products coming out with "Cumulative Update to SP1" and recently "EF 4.1 Update 1" and similar things, not to mention SQL Server. I really think this is confusing to customers. It certainly is to me. I'd like to know if you agree.
In my personal opinion, Microsoft has typically done a (poor) job with naming things - I think that's a fair statement with some exceptions like things like Lync, Kinect, Xbox and NuGet. Sometimes there's engineering reasons for versioning, but mostly it's a combination of marketing, lack of coordination between groups in a large company and a lack of community/customer outrage or just apathy. I think when folks work at a large company for many years it's easy to become complacent and stop fighting what is perceived as "small things."
Versioning and naming isn't set in stone. There isn't a technical reason that I know of to call something a Rollup Update Pack. Only willpower and organizational agreement is needed. If it's important to you, and your voice is heard, it'll become important to the people who make these decisions. Personally, I am a big fan of Semantic Versioning both in concept and in practice and I'd like to see its practical common sense take root at Microsoft.
Here's how the .NET Framework has been versioned so far. You are all familiar with it, probably because you've had to explain it to your boss at some point.
| Version | Runtime (CLR) | Framework |
| 1.0 | First Release | First Release |
| 1.1 | New | Small Changes |
| 2.0 | New | Lots of Changes |
| 3.0 | Same as 2.0 | WinFX libraries |
| 3.5 | Same as 2.0, but new C# 3 Compiler | Some Changes |
| 3.5 SP1 | Same as 2.0, with C# 3 | Whole Lot of Changes |
| 4 | New | Lots of Changes |
| 4.0 PU1 | Same as 4 | Workflow and Azure Changes |
We can't change the past, but we can influence the future. I would have probably made framework changes Point Releases (.1,.5, etc) and new CLRs or compilers should be Major Releases.
I suspect that product naming folks think that words are easier to understand than numbers, but I think they sell us short. Semantic Versioning would be easier to explain, deal with and sell. I think we need to stop with the Update, Refresh, Rollup, Pack stuff and just change numbers.
Going further, with the release of this new "EF 4.1 Update 1," what should they have called it? I would have said 4.1.5 or 4.2. Probably 4.2 if there were minor new features, and 4.1.5 if it's just patches.
- What are your thoughts, Dear Reader? What do you think about these "PUs" versus "SPs" or changing the version number? Do you care...How important is Semantic Versioning?
- Here's a Twitter Poll for you to spread around, or use the comments.
Photo via Creative Commons: Original Photo at http://www.flickr.com/photos/nicmcphee/422442291/
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
July 27, 2011 23:31
I totally agree. I don't like the direction they're headed with these type of updates. Call it 4.1.1, call it 4.2 but stick with a real version number imo.
just give us smaller nuget pieces not big frameworks http://blog.markrendle.net/2011/06/28/how-i-would-like-microsoft-to-distribute-net-v-next/
If I see 4.1.x, I think "ahh...some bug fixes. I can install this and not worry about breaking changes"
If I see 4.2, I think "I need to look at the new features to see what helps and what (might) hurt."
If I see 4.1 Update something or other, I have no idea what to think.
So, semantic versioning all the way.
If I see 4.2, I think "I need to look at the new features to see what helps and what (might) hurt."
If I see 4.1 Update something or other, I have no idea what to think.
So, semantic versioning all the way.
One extra problem with the "Platform Update 1 (PU1)" syntax is that if you see a version number somewhere, like an About... dialog, you might only see the version number.
So is that 4.0, or 4.0 PU1? You can't be sure unless you know the program you are using is configured to pull and display the right data.
So is that 4.0, or 4.0 PU1? You can't be sure unless you know the program you are using is configured to pull and display the right data.
I agree completely; their versioning is very inconsistent. Just look at the different versions of Windows (3.1, 95, 98, NT, 2000, ME, XP, Vista, 7). I would rather see the semantic versioning but hey, I don't call the shots at Microsoft.
I find it really frustrating when they have various "names" for the versions of the same product. As a rule, I would like it, if I put all the version numbers for example in an Excel sheet and be able to sort and see which version is the latest (or the oldest). What I mean by this, is that version numbers should clearly indicate the succession.
As a developer, whenever I have a say, I prefer semantic versioning. I come to think of it as "The accepted standard of versioning". Not everybody has to follow it, but those who do make it easier for all the others to understand.
As a developer, whenever I have a say, I prefer semantic versioning. I come to think of it as "The accepted standard of versioning". Not everybody has to follow it, but those who do make it easier for all the others to understand.
I hate, no LOATH, how versioning is done. The fact that I have to explain the .net versions to people is unacceptable. (it really is!)
I really think they should stick with semantic versioning. It just makes sense (to me!) If they want to go another route, I am fine with that, but please, oh please, keep it simple.
Maybe I am all doom and gloom right now, but what happen when/if they ship version 4.5? Am I going to have to tell me that (most likely) it contains PU1, and PU1 isn't some sort of optional upgrade to the 4.0 base?
I am a very short drive to the campus, and wouldn't mind meeting with the team to tell them this in person. Maybe hearing it from someone other than you will help. If not, we can always slap them with a salmon, right? :)
I really think they should stick with semantic versioning. It just makes sense (to me!) If they want to go another route, I am fine with that, but please, oh please, keep it simple.
Maybe I am all doom and gloom right now, but what happen when/if they ship version 4.5? Am I going to have to tell me that (most likely) it contains PU1, and PU1 isn't some sort of optional upgrade to the 4.0 base?
I am a very short drive to the campus, and wouldn't mind meeting with the team to tell them this in person. Maybe hearing it from someone other than you will help. If not, we can always slap them with a salmon, right? :)
When I saw "EF 4.1 Update 1" I actually thought that the versioning for all these different things is getting out of control. I don't want to have to keep track of what the latest version is and if I have it installed or not.
Actually I tweeted this to you a while back https://twitter.com/#!/rushonerok/status/51879523498725376
I don't care what the version number is. I care what this product does. Keep it up-to-date for me if not make it easy for me to update myself - drop the crazy versioning.
Actually I tweeted this to you a while back https://twitter.com/#!/rushonerok/status/51879523498725376
I don't care what the version number is. I care what this product does. Keep it up-to-date for me if not make it easy for me to update myself - drop the crazy versioning.
Scott,
Thanks for this post. I submitted my vote to Twitter poll but would like to explain that in more details in here.
In my opinion, number versioning for a platform like .NET is necessary. Generally, for big software projects that have frequent updates I think a precise number versioning is the best. By precise I mean that there should be a major version like 4 and a minor service pack update like 4.1.
I don't like the idea of real names for the .NET Framework or any other software with frequent updates because as time passes, it will be hard to remember what was what. A good example is Ubuntu versions. Every 1-2 years there is a new version and it's been always a hassle to talk about one of the recent versions with name.
Generally, I think Microsoft needs to change its strategies a little bit about the release times of products like ASP.NET MVC and how often they are released (especially now that it has had enough development in its early years). Release early, release often, is a great strategy but at the scale of work for Microsoft it has some downsides, too. For example, these frequent updates have made it hard to keep up the education and publication. Once a good resource (online or offline) comes out, it will be outdated quickly with a new version.
So all in all, I vote for precise/short number versioning and a more logical strategy for new releases and their frequency.
Thanks for this post. I submitted my vote to Twitter poll but would like to explain that in more details in here.
In my opinion, number versioning for a platform like .NET is necessary. Generally, for big software projects that have frequent updates I think a precise number versioning is the best. By precise I mean that there should be a major version like 4 and a minor service pack update like 4.1.
I don't like the idea of real names for the .NET Framework or any other software with frequent updates because as time passes, it will be hard to remember what was what. A good example is Ubuntu versions. Every 1-2 years there is a new version and it's been always a hassle to talk about one of the recent versions with name.
Generally, I think Microsoft needs to change its strategies a little bit about the release times of products like ASP.NET MVC and how often they are released (especially now that it has had enough development in its early years). Release early, release often, is a great strategy but at the scale of work for Microsoft it has some downsides, too. For example, these frequent updates have made it hard to keep up the education and publication. Once a good resource (online or offline) comes out, it will be outdated quickly with a new version.
So all in all, I vote for precise/short number versioning and a more logical strategy for new releases and their frequency.
I think there is a problem with marketing having a say in version numbers. Lets be honest, its the technical oriented persons who care, and we like versioning that we can understand.
Weve learned to live with versioning that doesnt make much sense but the naming is just as confusing for developers as 4.1.2 is for non-techies. Difference is, we care.
Weve learned to live with versioning that doesnt make much sense but the naming is just as confusing for developers as 4.1.2 is for non-techies. Difference is, we care.
Couldn't agree more. Semantic versioning is a must! Without it, we might as well be calling everything "Magic Unicorn Edition".
I do care, and really dislike the versioning scheme. But what was really bad was the 3.5 SP1 debacle. A service pack should not contain changes that are not backwards compatible. Yet this service pack did contain changes to the Thread class, removing some methods. The worst part was you wouldn't know it until the assembly was JIT-ted, if it had been compiled on a version without the service pack. That's all in addition to the general quality issues with that SP (I think it got rolled back by MSFT b/c it wasn't ready).
I know that complaint isn't directly related to the versioning scheme, but the versions should mean something. Major changes should only be included in major releases. Minor changes in minor releases. And so on. A service pack should only include additive changes.
I know that complaint isn't directly related to the versioning scheme, but the versions should mean something. Major changes should only be included in major releases. Minor changes in minor releases. And so on. A service pack should only include additive changes.
I agree with the versioning semantics, 100%. However, is it important to me? Sometimes it is, when it's a product that I have to make sure it is updated, but even then, sometimes it's hard enough determining the version. I don't care if it's a product that either auto-updates, or through some mechanism, informs me of available updates. This is one of the very reasons, I instantly became a fan of NuGet!! So, yes, it can be very important to me!
The EF naming is particularly confusing given it mixes version numbers and words. There's an implication that EF 4.2 (or 4.N) will be released some day; until then we simply have a 4.1.X revision known as "Update 1." And, as you called out, how many updates or revisions are we to expect under the 4.1 minor release?
I'm terribly excited about the way Microsoft developer tooling has been going in the last couple years. NuGet, MVC, and the like are fantastic and much needed additions to the community at large. I'd content that developers alike appreciate the general "happiness" Microsoft has been delivering as of late. All my legos fit.
That said, without a clearer roadmap (is there one we're all missing?), developers are left answering the same questions you're proposing. A consistent version naming or numbering scheme would address most of the frustration. It'd also make searching for version-specific help feasible and align with external tool version semantics like the one introduced by NuGet.
Suggested mantra as a take-away for the product teams: Convention vs. Confusion.
I'm terribly excited about the way Microsoft developer tooling has been going in the last couple years. NuGet, MVC, and the like are fantastic and much needed additions to the community at large. I'd content that developers alike appreciate the general "happiness" Microsoft has been delivering as of late. All my legos fit.
That said, without a clearer roadmap (is there one we're all missing?), developers are left answering the same questions you're proposing. A consistent version naming or numbering scheme would address most of the frustration. It'd also make searching for version-specific help feasible and align with external tool version semantics like the one introduced by NuGet.
Suggested mantra as a take-away for the product teams: Convention vs. Confusion.
Agree, use numbers!
These names are getting weird and giiiaaant unicornical names... thats a lot confusing for devs from diffent countries...
These names are getting weird and giiiaaant unicornical names... thats a lot confusing for devs from diffent countries...
When even the Microsoft guys make jokes about Microsoft's naming policies, you know it's a load of bull. I am strongly in favor of at least credible, publicly visible version numbers (semver is good but not the only option).
Semantic versioning all way. KevDog sums it up nicely, I don't want to search just to double check that we're only talking about bug fixes.
For things where the order or version matters, numbers, letters or roman numerals sure help. I like the return to numbering in Windows 7 (and hopefully Windows 8).
Heck, I even get confused with a series of fiction books or movies that don't have some method of telling me where to start the series and how to find the next one. (Star wars with its roman numeral episodes and the alphabet murder series was easy to follow for those casual customers)
Other than Autodesk, I get the impression that software companies are afraid to go over version number 10.
If they INSIST on keeping hard to follow names, could you at least suggest hexadecimal? ;-)
Heck, I even get confused with a series of fiction books or movies that don't have some method of telling me where to start the series and how to find the next one. (Star wars with its roman numeral episodes and the alphabet murder series was easy to follow for those casual customers)
Other than Autodesk, I get the impression that software companies are afraid to go over version number 10.
If they INSIST on keeping hard to follow names, could you at least suggest hexadecimal? ;-)
I'm one of a small number of devs in a big business unit of a really, really large company. My boss is not a programmer, nor is my grand-boss, great-grand-boss, or anyone else above me. Having to try and explain technical issues is tough enough, but most people can understand that 4.5 is more recent than 4.4.5 - it's not rocket surgery. Trying to understand why 4.1 Enterprise Rainbow Sprinkles Hotfix Rollup with Jam is more current than 4.1 Premium Chocolate Sauce Ramalamadingdong is impossible. I'd vote for semantic versioning, and I feel it's very important. Help us, Version 1.Kenobi...
Cool names are needed when you want to sell something. There is no need to sell us on .NET; we're in it up to our necks. So all we need is clarity. Next to each new version number we'll need an impressive list of features and fixes so we can sell it to our Powers That Be so they will be happy to move to that awesome new version because we'll benefit from the fixed bugs | productivity boost | happy customers | shiny logos.
I seriously dislike all the mini-updates, service packs, extras. I'll install them all on my machine (up to my neck already) but how about our deployment sites?
I seriously dislike all the mini-updates, service packs, extras. I'll install them all on my machine (up to my neck already) but how about our deployment sites?
Microsoft .net 4.0 Update 1 Small Business Professional Edition 2011.
What could possibly be wrong with that? Ha! Yes, Microsoft has a big issue with versioning and naming across all its products. Dotnet should follow Microsoft's own programming conventions, Major.Minor.Revision.Build is all you need.
Also, ".net" is a stupid name. Almost impossible to google (or bing). But it's too late for that I guess.
What could possibly be wrong with that? Ha! Yes, Microsoft has a big issue with versioning and naming across all its products. Dotnet should follow Microsoft's own programming conventions, Major.Minor.Revision.Build is all you need.
Also, ".net" is a stupid name. Almost impossible to google (or bing). But it's too late for that I guess.
You know, I don't really mind what naming / numbering scheme they pick as long as it is consistent and transparent. They could even use your "Magic Unicorn" idea as long as they stick to it.
My preference would be for semantic versioning, but I know that when you get a marketing exec involved in anything there is no longer any requirement for things to make sense. If they have to come up with some fancy-schmancy convention, at least provide us mere mortals with a timeline somewhere that tells us what the latest version is, and how previous versions relate to it.
My preference would be for semantic versioning, but I know that when you get a marketing exec involved in anything there is no longer any requirement for things to make sense. If they have to come up with some fancy-schmancy convention, at least provide us mere mortals with a timeline somewhere that tells us what the latest version is, and how previous versions relate to it.
I do care about semantic versioning and current different versioning styles for different products or even for the same product are very confusing to me.
I can understand arguments that for non-technical people numbers might not be the best way to differentiate versions although without real science involved we can't say whether names are better then numbers for them. Nevertheless I don't mind having some marketing name for product version unless it has a semantic version too.
I can understand arguments that for non-technical people numbers might not be the best way to differentiate versions although without real science involved we can't say whether names are better then numbers for them. Nevertheless I don't mind having some marketing name for product version unless it has a semantic version too.
I think for a company with many products, semantic versioning makes sense. Our company uses semantic versioning (majorRelease.databaseSchema.build) of our own design, but also uses (because we are based on the SW coast of Florida) fish names for the major releases. Sand Dollar, e.g., was the release that introduced multi-currency. We're currently on Scaled Sardine. Our customers routinely tell us the fish they are on, not the version. Our support staff tells R&D the version in which the defect is reported. We actually used the fish names only internally at first, but then customers learned there were fish names and preferred them: we now display the fish name in the title bar and on the startup screen.
The current MS naming system for .Net belongs in the "really dumb decisions made by smart people at large organizations" folder. Is there anyone at the helm?
Hank Fay
The current MS naming system for .Net belongs in the "really dumb decisions made by smart people at large organizations" folder. Is there anyone at the helm?
Hank Fay
Great article Scott!
As requested, here are my thoughts.
Just as you do, I prefer semantic versioning. It's clear and you can immediately see th overall size of impact of a newer version. All the additional naming like "platform update" or "refresh" cause confusion.
It already started with .net 3.0. A major version upgrade without major improvements, a system now used by Google Chrome and Mozilla FireFox. It's unclear, confusing and version numbers lose their meaning.
Another problem is that after a while, companies think they need to change the product name because version 27 doesn't sound that nice....
But most of all, how can we continue to develop when platform updates are released often. We cannot just upgrade solutions.(this is also a problem of my company, since most of the product is still written and developed in vb6... yes I mean visual basic 6.)
As requested, here are my thoughts.
Just as you do, I prefer semantic versioning. It's clear and you can immediately see th overall size of impact of a newer version. All the additional naming like "platform update" or "refresh" cause confusion.
It already started with .net 3.0. A major version upgrade without major improvements, a system now used by Google Chrome and Mozilla FireFox. It's unclear, confusing and version numbers lose their meaning.
Another problem is that after a while, companies think they need to change the product name because version 27 doesn't sound that nice....
But most of all, how can we continue to develop when platform updates are released often. We cannot just upgrade solutions.(this is also a problem of my company, since most of the product is still written and developed in vb6... yes I mean visual basic 6.)
KevDog said it great, here is my small addition:
If I see 4.1.x, I think "ahh...some bug fixes. I can install this and not worry about breaking changes"
If I see 4.2, I think "I need to look at the new features to see what helps and what (might) hurt."
If I see 5.0, I think "Major changes, might take some effort to upgrade ot it."
If I see 4.1 Update something or other, I have no idea what to think.
So, semantic versioning all the way!!!
I'm not a big fan of service packs, rollups, etc. I don't know if they're the result of putting versions out with the year in the version (Windows 2000, Office 2007, etc.) where version 2000.1 didn't match the marketing vision so "alternative" schemes were devised and "service packs" appeared.
If I see 4.1.x, I think "ahh...some bug fixes. I can install this and not worry about breaking changes"
If I see 4.2, I think "I need to look at the new features to see what helps and what (might) hurt."
If I see 5.0, I think "Major changes, might take some effort to upgrade ot it."
If I see 4.1 Update something or other, I have no idea what to think.
So, semantic versioning all the way!!!
I'm not a big fan of service packs, rollups, etc. I don't know if they're the result of putting versions out with the year in the version (Windows 2000, Office 2007, etc.) where version 2000.1 didn't match the marketing vision so "alternative" schemes were devised and "service packs" appeared.
I looked at the poll, but I wasn't sure how to vote on it. Needs examples.
But fundamentally I'd say: Use numbers! That's what they're for! If the latest "update" to EF 4.1 is minor, call it EF 4.1.1. Or EF 4.2 if it's bigger. Sure, it's subjective, but the numbering tells us what the team that produced it thinks about the nature of the release and how much compatibility testing we'll need to do.
What really drove me mad was the .NET CLR numbering. 1.0, 1.1, 2.0, so far, so good. Then came 3.0. Which wasn't really a new version of the CLR at all; it was just some additional libraries. Marketing is the only thing that can explain the "3.0" moniker; it should've been .NET 2.5. Then came 3.5, which should've been 3.0, but failing that, should've been 4.0. One hopes that now that we've reached 4.0 we can leave that insanity behind.
But fundamentally I'd say: Use numbers! That's what they're for! If the latest "update" to EF 4.1 is minor, call it EF 4.1.1. Or EF 4.2 if it's bigger. Sure, it's subjective, but the numbering tells us what the team that produced it thinks about the nature of the release and how much compatibility testing we'll need to do.
What really drove me mad was the .NET CLR numbering. 1.0, 1.1, 2.0, so far, so good. Then came 3.0. Which wasn't really a new version of the CLR at all; it was just some additional libraries. Marketing is the only thing that can explain the "3.0" moniker; it should've been .NET 2.5. Then came 3.5, which should've been 3.0, but failing that, should've been 4.0. One hopes that now that we've reached 4.0 we can leave that insanity behind.
I understand the need to name something that has taken years to be more than a 0.1 increment. It's often not enough to convey the importance of the update. Also, there's often a need to synchronize versions (Entity Framework, WPF etc.. with the .NET version that they fall under).
For this reason, I would suggest using a date (and quarter if necessary) system. This would carry a rule that anything released in the same quarter is compatible (or part of the same product). It would also encourage updates (who wants to release something targeting a 2004 version of .NET). Bug fixes would be released as service packs. This makes the whole process of version much less subjective.
For this reason, I would suggest using a date (and quarter if necessary) system. This would carry a rule that anything released in the same quarter is compatible (or part of the same product). It would also encourage updates (who wants to release something targeting a 2004 version of .NET). Bug fixes would be released as service packs. This makes the whole process of version much less subjective.
+1 for changing *some* global version number with every release, and making said version number prominent in the name of the product, downloads, etc. I hate that I have to use things like this (why isn't it built in?) or worse, having to probe with Reflection to see if a feature is available before eating a link failure at runtime or experiencing a strange deserialization error.
Platform Update 1 was a great example of what *not* to do- I had to dig around for awhile verifying that there wasn't anything I cared about (or that was going to break anything I cared about). The only real info I could find was on the WF blog, so it was unclear whether they were describing the entire contents of the release, or just the WF-relevant bits.
Platform Update 1 was a great example of what *not* to do- I had to dig around for awhile verifying that there wasn't anything I cared about (or that was going to break anything I cared about). The only real info I could find was on the WF blog, so it was unclear whether they were describing the entire contents of the release, or just the WF-relevant bits.
Agreed 100%. Semantic versioning is clear, understandable and the most important it is well-established and well-known, so if you use it - everyone can be sure what is in your next release.
I've tried several times writing a reply here but I end up almost with namecalling every time because of the sheer stupidity that has gone into this naming scheme.
Get the person(s) that decided on these naming schemes on the line and have him call me, I have some customers he can deal with next year when we upgrade to 4.0 and have to explain why Microsoft *yet again* changed their naming scheme and that a Product Update is sort-of but apparently not quite like a Service Pack and, yes, it is *still* required. I know that EF is something we would ship but I have no hope for the naming of .NET any more.
I agree completely with you Scott. This is just silly, at least they could be consistent when they named the stuff, Service Pack 1, Update Pack 1, what is next? Semi-Minor Bidirectional Adjustment Change 1.5?
Get the person(s) that decided on these naming schemes on the line and have him call me, I have some customers he can deal with next year when we upgrade to 4.0 and have to explain why Microsoft *yet again* changed their naming scheme and that a Product Update is sort-of but apparently not quite like a Service Pack and, yes, it is *still* required. I know that EF is something we would ship but I have no hope for the naming of .NET any more.
I agree completely with you Scott. This is just silly, at least they could be consistent when they named the stuff, Service Pack 1, Update Pack 1, what is next? Semi-Minor Bidirectional Adjustment Change 1.5?
Amen! From your mouth to God's ears.
All of your examples are spot on and the EF 4.1 Update 1 was just the most recent one where I looked at it and shook my head.
The worst one because of its far-reaching impact was the whole .NET Framework 2.0/3.0/3.5/3.5SP1 debacle. I have completely lost count of the number of times I've had to explain to colleagues and also clients what the difference really was between the different CLR 2.0 releases (it's the same except new extra assemblies! well.. 99% the same! oh forget it..). It was especially bad for many large corporate IT departments because people without the time or interest in understanding the messed up naming scheme held back approval of deployment of .NET 3.5 SP1 over .NET 2.0 for years in some cases because of fear of the impact.
It's not just a developer thing, although that's huge, but also a matter of policy at the IT department level for the really big things. Semantic versioning may have a geeky ring to it, but it's much, much easier to explain even to non-developers than the current random text nonsense getting put out.
All of your examples are spot on and the EF 4.1 Update 1 was just the most recent one where I looked at it and shook my head.
The worst one because of its far-reaching impact was the whole .NET Framework 2.0/3.0/3.5/3.5SP1 debacle. I have completely lost count of the number of times I've had to explain to colleagues and also clients what the difference really was between the different CLR 2.0 releases (it's the same except new extra assemblies! well.. 99% the same! oh forget it..). It was especially bad for many large corporate IT departments because people without the time or interest in understanding the messed up naming scheme held back approval of deployment of .NET 3.5 SP1 over .NET 2.0 for years in some cases because of fear of the impact.
It's not just a developer thing, although that's huge, but also a matter of policy at the IT department level for the really big things. Semantic versioning may have a geeky ring to it, but it's much, much easier to explain even to non-developers than the current random text nonsense getting put out.
The audience is important. When releasing something to the general (i.e. non-technical) public, providing a name like "Foo X.Y Update 1" may make some sense. However, the audience for .NET libraries is obviously technical, and the "off the wall" naming going on here is actually detrimental. You don't have to search the blogosphere for very long before you find a LOT of people complaining about this. Microsoft should stick to semantic versioning here and save us from the likes of ".NET 3.5 SP1" and "Entity Framework 4.1 Update 1".
I can understand rollup and service pack naming for widely deployed products which have wide end user impact but for developer tools it makes no sense to me that the naming is not semantic.
Not only are the names not semantically correct, but they are not consistent across products and sometimes inconsistent within the same product! (grr)
I feel that Microsoft is naming products based on placating IT managers, as if to say: "Hey, this is not a major update, you can use it. Look it's just update 1, we haven't even changed the released version number".
Not only are the names not semantically correct, but they are not consistent across products and sometimes inconsistent within the same product! (grr)
I feel that Microsoft is naming products based on placating IT managers, as if to say: "Hey, this is not a major update, you can use it. Look it's just update 1, we haven't even changed the released version number".
I agree with Scott.
.NET is for programmers. Programmers like numbers and logic.
.NET is for programmers. Programmers like numbers and logic.
I totally agree! Give us numbers! Numbers are easy to compare. I think big companies get mired in apathy or something and finally just say "Screw it!" to naming conventions that make sense. Microsoft does it (with some exceptions). Intel does it. Lots of computer manufacturers do it. Please, PLEASE, above all pick names that make sense and are easy to compare. If possible also pick names that make me think your stuff is awesome. But if I only get to choose one, I'll take logical over awesome.
I agree (strongly, loudly, etc), let's try for some consitency.
It's not even the difficulty in following EF and .Net framework versions, as a web dev I also have to contend with version numbers for Windows, SQL Server, Visual Studio, HTML standards, jQuery, a variety of logging and other useful packages (mostly on NuGet, but still more version numbers), and so on.
I'm not against service packs, rollups, cumulative updates, etc, but we need to decide on one word and use it (and include the end version number the cumulative packaged rollup will leave us on).
Worst case, if semantic numbering scares the sales and marketing types, maybe switch to a hybrid year + semantic where the major version is the year and the minor and patch number continue to be standard incrementals. So we do a major release and we call it .Net Framework 2012.0.0 followed by a minor release to 2012.1.0 and patch a few times to 2012.1.6
It's not even the difficulty in following EF and .Net framework versions, as a web dev I also have to contend with version numbers for Windows, SQL Server, Visual Studio, HTML standards, jQuery, a variety of logging and other useful packages (mostly on NuGet, but still more version numbers), and so on.
I'm not against service packs, rollups, cumulative updates, etc, but we need to decide on one word and use it (and include the end version number the cumulative packaged rollup will leave us on).
Worst case, if semantic numbering scares the sales and marketing types, maybe switch to a hybrid year + semantic where the major version is the year and the minor and patch number continue to be standard incrementals. So we do a major release and we call it .Net Framework 2012.0.0 followed by a minor release to 2012.1.0 and patch a few times to 2012.1.6
I care! Please bring some clarification to this! I can understand them trying to capitalize on the "EF 4.1" thing and not wanting to lose the PR cycle thats all 4.1-based, but seriously, 4.1.1 wouldn't have been so different and we engineers understand that 4.1.1 is the *same* as 4.1-with-fixes. You left something out. Don't forget that release 4.0 is actually 4.0.123.13431432 and we have to just remember that 4.0 SP1 is actually 4.0.5333.34234234. So really, 4.1-with-fixes should be just a larger number 4.1.34.45435.
The community complained about the .net "versioning strategy" rather loudly with WinFX. During much of the beta, it was simply, .net 2 + WinFX. Many people liked this and it made sense. Choosing to call this "3.0" was simply stupid and confusing, but that's what stuck.
Why does devdiv have such a hard time getting versioning right, when the others don't? Sure, people say "XP", "Vista", "ME", etc.. but those are friendly names. Within Windows, you have versions 1 to 6. Confused with "windows server 2008" vs "windows server 2008 R2"? try typing in "winver", and find 6.0 and 6.1. Microsoft Office? I'm running version 14.0, having just upgraded from 12.0.
And I could care less what "friendly name" people give releases. "Snow Leapord", "Natty Narwhal", whatever. Want to call the next release of .net "Microsoft Windows development productivity platform 2012 with Microsoft Azure"? fine. (we know the names will be bad, we live with it) But give the actual *version numbers* meaning. The .NET platform has behavior and capability around version number management, why not use it? Why not be sane? It's bad enough that the actual CLR version, the compiler versions, and libraries change randomly compared to each other and the .net version.... but now we don't even get numbers at all? "Update 1", wow.
TL;DR: wtf, devdiv?
Why does devdiv have such a hard time getting versioning right, when the others don't? Sure, people say "XP", "Vista", "ME", etc.. but those are friendly names. Within Windows, you have versions 1 to 6. Confused with "windows server 2008" vs "windows server 2008 R2"? try typing in "winver", and find 6.0 and 6.1. Microsoft Office? I'm running version 14.0, having just upgraded from 12.0.
And I could care less what "friendly name" people give releases. "Snow Leapord", "Natty Narwhal", whatever. Want to call the next release of .net "Microsoft Windows development productivity platform 2012 with Microsoft Azure"? fine. (we know the names will be bad, we live with it) But give the actual *version numbers* meaning. The .NET platform has behavior and capability around version number management, why not use it? Why not be sane? It's bad enough that the actual CLR version, the compiler versions, and libraries change randomly compared to each other and the .net version.... but now we don't even get numbers at all? "Update 1", wow.
TL;DR: wtf, devdiv?
100% for proper version numbers. BUT, I am skeptical. Exactly the same arguments were brought forward when this whole mess started with .Net 3 not being called .Net 2.1 (or 2.5 or something). Have a look here and here. All commenters agreed that the naming was terrible, and yet the MS management in charge of that ignored it and said their stupid names were better. Seems to me that exactly the same people still run the show, so why would they come to their senses now?
+50 - The naming of things at MS has never been great, and it only seems to be getting worse. I even have to take exception with your list of good names: who thought it would be a good idea for MS to release two completely different products/technologies that are pronounced the same (Lync vs LINQ)? I'm for semantic versioning, but if we can't have that, can we at least have some consistency? I mean, releasing "SQL Server 2008 R2" in 2010? What's wrong with SQL Server 2010? And what's the latest service pack for SQL 2008? Well, it's either 1 or 2, depending on whether you forgot to mention "R2" or not...
My suggestion for a rule-of-thumb would be that product names can be no more than three words long, plus an identifiable version number that is consistently applied. If people have to pause and take a breath while saying your product name out-loud, you've failed hard.
My suggestion for a rule-of-thumb would be that product names can be no more than three words long, plus an identifiable version number that is consistently applied. If people have to pause and take a breath while saying your product name out-loud, you've failed hard.
Glad you raised this Scott
Yuss not alone in this! Had an epidemic a few weeks back where trying to come to grips with Azure and figuring out why my AppCache implementation kept on failing, ended up I had the wrong version of the SDK, because it was versioned weirdly. Yet MS had articles up on how to utilise all these new features, but all of them neglect to say that this is only available in the CTP version of the SDK. Tying along a proper x.y.x version number to releases is a major step in the right direction, what would be hugely beneficial too, is MS and We (the community) refer to these version numbers when making blog posts etc... I lost count how many blogs I came accross describing how to implement AppCache in Azure, yet only one blog (Shiju Varghese thanks dude!) mentioned that these features are only available in the CTP release of the SDK.
Things like NuGet is awesome! But MS needs to "adapt" the platform (or something similar) on a wider scale, similar to APT in Debian/Ubuntu. You know its there and it works and that is the standard way of doing things. Going "package" hunting is a waist of time, and keeping up-to-date with latest releases is extremely time consuming.
I'm off the beaten track, but the issue you raised is just the tip of the ice-berg when it it comes to MS patch/update releases.
Yuss not alone in this! Had an epidemic a few weeks back where trying to come to grips with Azure and figuring out why my AppCache implementation kept on failing, ended up I had the wrong version of the SDK, because it was versioned weirdly. Yet MS had articles up on how to utilise all these new features, but all of them neglect to say that this is only available in the CTP version of the SDK. Tying along a proper x.y.x version number to releases is a major step in the right direction, what would be hugely beneficial too, is MS and We (the community) refer to these version numbers when making blog posts etc... I lost count how many blogs I came accross describing how to implement AppCache in Azure, yet only one blog (Shiju Varghese thanks dude!) mentioned that these features are only available in the CTP release of the SDK.
Things like NuGet is awesome! But MS needs to "adapt" the platform (or something similar) on a wider scale, similar to APT in Debian/Ubuntu. You know its there and it works and that is the standard way of doing things. Going "package" hunting is a waist of time, and keeping up-to-date with latest releases is extremely time consuming.
I'm off the beaten track, but the issue you raised is just the tip of the ice-berg when it it comes to MS patch/update releases.
Microsoft's schizophrenic versioning bothers me. There's no logic to it and it changes every few years.
I think Microsoft needs to make a better distinction between technical version numbers and marketing version numbers, and then use them consistently in the appropriate contexts. Technical version numbers are useful for developers and should follow a logical scheme that indicates the magnitude of the changes. Marketing version numbers are appropriate for managers and generic computer users, and can be anything, like a year or combination of letters.
Long live semver.org
I think Microsoft needs to make a better distinction between technical version numbers and marketing version numbers, and then use them consistently in the appropriate contexts. Technical version numbers are useful for developers and should follow a logical scheme that indicates the magnitude of the changes. Marketing version numbers are appropriate for managers and generic computer users, and can be anything, like a year or combination of letters.
Long live semver.org
Where's the Google +1 button, nerd?
Please commence with sane numbering. Especially for developer software. Letting marketing people decide how to manage versioning schemes is retarded, let them decide the box color and call it a day.
Please commence with sane numbering. Especially for developer software. Letting marketing people decide how to manage versioning schemes is retarded, let them decide the box color and call it a day.
Couldn't agree more. Semantic version numbers please. If you want to amend a certain version number with a nice name too, I don't care (SP1 Update 3 Rollup Pack, Magic Unicorn Edition, whatever). But the full semantic version number should be clearly marked.
Microsoft has long tripped over itself with products, product versioning, and marketing. Even non-developers can generally understand what is meant by common versioning. 2.0 is greater than 1.0, etc. As for the .NET versioning it all went awry with 3.0. So, yes, a change to simple versioning would be appreciated.
As for Microsoft products the precendence was set more than a decade ago with the jump from Windows 3.1 to Windows 95, and coming up with Office 5.1 on the second release. While names go well for the OS (Snow Leopard, Lion, XP, Vista), they do not explain much for the developer who really just want to do a version check.
Microsoft has had some great products (Sync, Communicator, SyncToy), that few know about. (See: Sync for the cloud) But marketers must be better at driving the cohesive message and stop trying to shove Windows Live x when it is nothing more than a re-badged product. Perhaps, Scott, you may have greater pull with TPTB at Microsoft to show how great Microsoft is as a software development company.
As for Microsoft products the precendence was set more than a decade ago with the jump from Windows 3.1 to Windows 95, and coming up with Office 5.1 on the second release. While names go well for the OS (Snow Leopard, Lion, XP, Vista), they do not explain much for the developer who really just want to do a version check.
Microsoft has had some great products (Sync, Communicator, SyncToy), that few know about. (See: Sync for the cloud) But marketers must be better at driving the cohesive message and stop trying to shove Windows Live x when it is nothing more than a re-badged product. Perhaps, Scott, you may have greater pull with TPTB at Microsoft to show how great Microsoft is as a software development company.
I totally agree with Semantic Versioning, they are easy to understand.
I think that MARKETING PEOPLE SHOULD BE KEPT AWAY from software development, look at what those guys made with Windows "Vista" and all those idiotic brand names. How would I know that professional is better than premium!?!
I think that MARKETING PEOPLE SHOULD BE KEPT AWAY from software development, look at what those guys made with Windows "Vista" and all those idiotic brand names. How would I know that professional is better than premium!?!
I cannot agree anymore. Microsoft completely is the king at making versions long winded and stupid. I can't express my dismay anymore towards how they are managing their CTP's and crap like that. The web is pretty much diluted with out dated CTP versions and out dated dll's. So .NET with the GAC was an attempt to solve dll hell, try solving that on the web. They've shot themselves in the foot.
I was doing some work with WCF Data Services with WP7, it was natural to search the usual terms in google, about 70% of the articles I located were the general gist, I thought I was on the right track, then it all went wrong, I realised I had the wrong .dll version, not to mention their version info in the dll wasn't even changed, so it was extremely hard to tell if I had a new version or not.
So then I realised, the team did a reset on the dll last year, and only then did I find the *latest* version of this dll dated in Oct '10. So again I was a bit wary whether or not I have the latest one, but it seems like it.
I find that all these teams within Microsoft are doing a pretty poor job with keeping things on the web up to date. Not sure how they're going to manage this dll hell, but it's quite annoying when you go digg through the web, and you find all these blog entries mainly from microsoft employees themselves, with examples always out dated.
Very discouraging to develop against some of the CTP's that come out, I'm sure that not everyone has the time to stay in the loop with everything everyday. They seem to some what assume a lot of people are constantly following product X and will be aware of new changes and updates to it.
I'm feeling more and more discouraged by Microsoft these days, they were pretty good originally but now they're turning into a dogs breakfast.
It annoys me so much that, with everything there's a subtle difference in terms of development. For example we don't get BeginInvoke for Action methods in WP7, that's cool, could you maybe find a way to add warnings or some how apply some filtering out on the intellisense for those entries?
All these small discrepancies, and not to mention the abundance of "NotSupportedExceptions" in silverlight is also aggravating. Sure I know it's a lot of work, but hey, if Microsoft's intention was to make skills transferable, i.e. WPF dev can pick up Silverlight easily or SL devs can pick up WP7 dev work easily, then they need to fix these bloody tools up. Not just wack it together, and then hope that someone encounters a problem that's not supported. Completely frustrates me, developers should be expending time on writing business logic, not unraveling mysteries in these frameworks that have methods that are half not supported but appear to be.
Enough of my rant, I've gone off tangent with my reply, yes Microsoft versioning sucks big time, and they suck in a lot of other areas too.
I was doing some work with WCF Data Services with WP7, it was natural to search the usual terms in google, about 70% of the articles I located were the general gist, I thought I was on the right track, then it all went wrong, I realised I had the wrong .dll version, not to mention their version info in the dll wasn't even changed, so it was extremely hard to tell if I had a new version or not.
So then I realised, the team did a reset on the dll last year, and only then did I find the *latest* version of this dll dated in Oct '10. So again I was a bit wary whether or not I have the latest one, but it seems like it.
I find that all these teams within Microsoft are doing a pretty poor job with keeping things on the web up to date. Not sure how they're going to manage this dll hell, but it's quite annoying when you go digg through the web, and you find all these blog entries mainly from microsoft employees themselves, with examples always out dated.
Very discouraging to develop against some of the CTP's that come out, I'm sure that not everyone has the time to stay in the loop with everything everyday. They seem to some what assume a lot of people are constantly following product X and will be aware of new changes and updates to it.
I'm feeling more and more discouraged by Microsoft these days, they were pretty good originally but now they're turning into a dogs breakfast.
It annoys me so much that, with everything there's a subtle difference in terms of development. For example we don't get BeginInvoke for Action methods in WP7, that's cool, could you maybe find a way to add warnings or some how apply some filtering out on the intellisense for those entries?
All these small discrepancies, and not to mention the abundance of "NotSupportedExceptions" in silverlight is also aggravating. Sure I know it's a lot of work, but hey, if Microsoft's intention was to make skills transferable, i.e. WPF dev can pick up Silverlight easily or SL devs can pick up WP7 dev work easily, then they need to fix these bloody tools up. Not just wack it together, and then hope that someone encounters a problem that's not supported. Completely frustrates me, developers should be expending time on writing business logic, not unraveling mysteries in these frameworks that have methods that are half not supported but appear to be.
Enough of my rant, I've gone off tangent with my reply, yes Microsoft versioning sucks big time, and they suck in a lot of other areas too.
My personal pref is for semantic versioning (perhaps with the addition of odd minors for "future" and even minors for "stable") but I wouldn't care for which specific schema will be used, as long as it would be a consistent one.
But it is probably not as terrible as some of the heated responses here say.
per the .NET versions table, there was also .NET 2.0 SP1 which sort of brought the 2.0 to a state it could run 2.0 targeted c#3 code (but 3.0+ specific libraries) and was easier to sneak past hysteric sys-admins. so it did make sense to keep the number and call it a Pack, otherwise it would have hit a higher wall for install.
But it is probably not as terrible as some of the heated responses here say.
per the .NET versions table, there was also .NET 2.0 SP1 which sort of brought the 2.0 to a state it could run 2.0 targeted c#3 code (but 3.0+ specific libraries) and was easier to sneak past hysteric sys-admins. so it did make sense to keep the number and call it a Pack, otherwise it would have hit a higher wall for install.
+1 for semantic versioning.
The thing I can't get is that why would you do it any other way? It just feels lazy to not use semantic versioning...
The thing I can't get is that why would you do it any other way? It just feels lazy to not use semantic versioning...
I could not agree more - semantic versioning is the way to go. I had it to here with the buckshot versioning schemes. And, in the same vein, let's kill so called "rapid release cycles" that update the major version every 6 weeks (you know who you are, Mozilla and Google).
+1 for semantic versioning - personally I think it's easier to understand than the rollup, hotfix blah blah because it's unambiguous. Microsoft's record to date on naming things is pretty laughable (with the exception of xbox and a few exceptions to the rule) and whenever I see any new product name I'm reminded of this classic: http://www.youtube.com/watch?v=EUXnJraKM3k
This naming is annoying, version numbers please.
When I want to deploy an app internally on our network I don't need an installer an xcopy deploy onto the network is the quick and simple deployment strategy. In order for this to work I just want to be able to ask IT what version of .NET is installed (gone out through windows update) 2, 3.0, 3.5, 4.0....
I can't see IT saying yeah it's 4.0 PU1 they will just tell me 4.0 and allow the confusion and problems to ensue. Don't expect everyone to have knowledge of every incremental version of .NET just expect them to know 4.1 is higher than 4.0 or for minor updates 4.1.1 is greater than 4.1.0.
When I want to deploy an app internally on our network I don't need an installer an xcopy deploy onto the network is the quick and simple deployment strategy. In order for this to work I just want to be able to ask IT what version of .NET is installed (gone out through windows update) 2, 3.0, 3.5, 4.0....
I can't see IT saying yeah it's 4.0 PU1 they will just tell me 4.0 and allow the confusion and problems to ensue. Don't expect everyone to have knowledge of every incremental version of .NET just expect them to know 4.1 is higher than 4.0 or for minor updates 4.1.1 is greater than 4.1.0.
Adding my voice to the cry for semantic versioning. I wish you luck on your crusade, Scott!
I'm a .NET developer. I want to create a mobile application for managing inventory in a warehouse.
I've seen cool demos of Windows Phone 7 and Silverlight at local user groups and online. I'd like to use Microsoft's current mobile platform. So, I need information about a non-telephone version of Windows Phone 7. I don't need any of the personalized contacts, photos, games, music, etc. stuff. I need rugged devices with bar code scanners.
I found this versioning/naming mess on Wikipedia:
Windows Phone 7 is currently based on Windows Embedded CE 6.0 R3 with some features borrowed from Windows Embedded CE 7.0. Windows Embedded Compact 7 (formerly known as Windows Embedded CE 7.0) was released on March 1, 2011. The CTP version of the Platform Builder IDE for Windows Embedded Compact 7 is designed as plug-in for Microsoft Visual Studio 2008 and requires Service Pack 1. On 10 January 2011, Microsoft announced Windows Embedded Handheld 6.5. The operating system has compatibility with Windows Mobile 6.5.
WTF? Shut up and take my money!
I've seen cool demos of Windows Phone 7 and Silverlight at local user groups and online. I'd like to use Microsoft's current mobile platform. So, I need information about a non-telephone version of Windows Phone 7. I don't need any of the personalized contacts, photos, games, music, etc. stuff. I need rugged devices with bar code scanners.
I found this versioning/naming mess on Wikipedia:
Windows Phone 7 is currently based on Windows Embedded CE 6.0 R3 with some features borrowed from Windows Embedded CE 7.0. Windows Embedded Compact 7 (formerly known as Windows Embedded CE 7.0) was released on March 1, 2011. The CTP version of the Platform Builder IDE for Windows Embedded Compact 7 is designed as plug-in for Microsoft Visual Studio 2008 and requires Service Pack 1. On 10 January 2011, Microsoft announced Windows Embedded Handheld 6.5. The operating system has compatibility with Windows Mobile 6.5.
WTF? Shut up and take my money!
+1 for semantic versioning with one holdback: I really like that Microsoft has been able to release some great stuff without requiring that we wait for the next version of Visual Studio/.net. (Entity Framework 4.1 for example, and RIA Services -- I love that stuff!)
With that said, we are an ISV. We need to have some reasonably intelligible way of communicating our runtime requirements to our customers -- something better than ".Net framework 4, SP1, Update 2, Rollup 3, with RIA Services 2 SP1, Silverlight 4, with Silverlight toolkit 2." (granted that's an exaggeration, but you get my point).
With that said, we are an ISV. We need to have some reasonably intelligible way of communicating our runtime requirements to our customers -- something better than ".Net framework 4, SP1, Update 2, Rollup 3, with RIA Services 2 SP1, Silverlight 4, with Silverlight toolkit 2." (granted that's an exaggeration, but you get my point).
+1 for Semantic Versioning here. And why can't I just +1 the comments that I like?
I agree with the semantic versioning as well. I really dislike releases as Updates, Service Packs that add features, and other silliness in naming.
I've always believed the reason that Microsoft uses things like Entity Framework 4.1 Update 1 was for the IT shops that have very strict rules around getting software approved. It seems like once the IT (or security) department approves Entity Framework 4.1, then you can still get by using Entity Framework 4.1 Update 1 without having to get it re-approved whereas Entity Framework 4.1.1 might require another approval process. But that was just a guess.
I've always believed the reason that Microsoft uses things like Entity Framework 4.1 Update 1 was for the IT shops that have very strict rules around getting software approved. It seems like once the IT (or security) department approves Entity Framework 4.1, then you can still get by using Entity Framework 4.1 Update 1 without having to get it re-approved whereas Entity Framework 4.1.1 might require another approval process. But that was just a guess.
+1 from here for you trying to sort this out, but I'm skeptical that even if you succeed the effect will last very long. Look how long microsoft.com/net lasted after your triumph before it turned back into crap.
From the outside, the obvious stupidity associated with names like ".NET 3.5 SP1 GDR" is the clearest demonstration of how true the nasty things written in the comments at mini-microsoft must be.
If the people who choose these numbers need a justification for leaving the version numbering to the engineers, it should be that their blundering makes the whole organisation look dysfunctional.
We all know that MS is riven by internal squabbling and petty feifdoms, but the less often we're reminded of it, the better. Distilling that discord into a stupid product name that then hangs around for ever 'gives bile a permalink' in an even worse way than you meant when you coined the phrase.
From the outside, the obvious stupidity associated with names like ".NET 3.5 SP1 GDR" is the clearest demonstration of how true the nasty things written in the comments at mini-microsoft must be.
If the people who choose these numbers need a justification for leaving the version numbering to the engineers, it should be that their blundering makes the whole organisation look dysfunctional.
We all know that MS is riven by internal squabbling and petty feifdoms, but the less often we're reminded of it, the better. Distilling that discord into a stupid product name that then hangs around for ever 'gives bile a permalink' in an even worse way than you meant when you coined the phrase.
This is not about whether semantic versioning is more meaningful or helpful or not. This is about whether Microsoft's Marketing team has a say or not, because Microsoft's Marketing team does not give a flying @#$% what developers think about version names. They are going to use whatever looks like is going to get people showing up to spend money on the platform, period.
You guys are all wasting your time. Go home.
You guys are all wasting your time. Go home.
Also, Scott proposes 4.1.5. Shame on Scott!! x.x.5 as a first incremental revision??! Sheesh, dude! Use x.x.1 next after x.x or just stop talking!!
I agree with you with a small exception: Versioning this PU1 with 4.1.5 doesn't make sense for me. I would start with 4.1.1, next PU gets version number 4.1.2 and so on...
Another thing I don't really understand and like is NuGet package versioning. As packages are managed at solution level and under normal circumstances you won't need two different versions within one solution (containing one product and related projects), the NuGet folder structure /packages/[PackageName]/[Version]/[Contents] doesn't make sense for me. And the packages folder structure is not yet supported by VS 2010 SP1, too. This structure especially makes problems with subversion et al because when updating a package NuGet removes the version N folder and creates a new version N+x folder, which cannot be tracked by version control systems and makes it really hard to reapply own patches or modifications to packages because you don't have a history for the files you've modified/patched.
Another thing I don't really understand and like is NuGet package versioning. As packages are managed at solution level and under normal circumstances you won't need two different versions within one solution (containing one product and related projects), the NuGet folder structure /packages/[PackageName]/[Version]/[Contents] doesn't make sense for me. And the packages folder structure is not yet supported by VS 2010 SP1, too. This structure especially makes problems with subversion et al because when updating a package NuGet removes the version N folder and creates a new version N+x folder, which cannot be tracked by version control systems and makes it really hard to reapply own patches or modifications to packages because you don't have a history for the files you've modified/patched.
I'm a big fan of semantic versioning, its well documented and easy to understand. I personally also like names as well similar to Ubuntu. I know others don't prefer it, but I think it's easier to bring it up in conversation with non-technical people. Semantic versioning should be the basis though. I prefer names for when the major segment changes; I can just imagine trying to get a framework upgraded with a new name for each minor and revision segment. It'd be easier to go to superiors and say, "Hey I need you guys to run this update for Magic Unicorn of Entity Framework, it's 4.1.1." Instead of, "Hey can you guys install this update for Magic Unicorn of Entity Framework to make it Ninja Unicorn? It's only a small update that'll take us from 4.1.0 to 4.1.1, nothing else has changed I swear!" One request though, for God's sake make it consistent!
I totally agree. Versioning at the moment is so confusing, I can never remember what is compatible with what without first stopping to think it through. Please keep trying until they finally agree with you.
Scott--So glad to hear you reaching out to customers for feedback on this, and so sad that you feel that you would be perceived as Chicken Little for pointing out a problem that is so huge that nearly all customers would complain about it if they felt Microsoft would listen. Please keep it up!
Maybe simpler versioning would have helped me at work. I recently received a new PC as part of a PC refresh and I asked the obvious question: why no win 7?
The answer I received was because win 7 only supports .net 3.5 and 4.0 and would not support legacy applications developed in 2.0. Being a former .net developer, I tried to explain that 2.0 was a subset of 3.5 and that would work. (hopefully I can become a .net developer again :) )
Maybe I'm wrong but if I'm right, there are 1000+ engineers and developers that would love to move to win 7 and the only reason we can't is because someone didn't understand .net versioning!
The answer I received was because win 7 only supports .net 3.5 and 4.0 and would not support legacy applications developed in 2.0. Being a former .net developer, I tried to explain that 2.0 was a subset of 3.5 and that would work. (hopefully I can become a .net developer again :) )
Maybe I'm wrong but if I'm right, there are 1000+ engineers and developers that would love to move to win 7 and the only reason we can't is because someone didn't understand .net versioning!
bc84 - Yes, Since 3.5 *IS* .NET 2.0 CLR, you can (and I do) run .NET 2 apps on it happily. You can confirm this in Add Remove Features. Sigh.
I can't agree more. I love the example of VS versus Windows. Words can be confusing, numbers are not.
Thanks for bringing this up and trying to get something done about it. I totally agree.
I'm old fashioned. I believe in the basic idea that the version should define a functionality and compatibility set but you can patch to your heart's content to fix defects. E.g. .NET 2.0 defines a set of functionality and compatibility and .NET 2.0 SPx is a set of patches to *resolve defects*. Not one inch of new functionality, no matter how bad you want to. .NET 2.0 SP1 actually debuted new types (DateTimeOffset for one, actually credited to .NET 3.0) and did a bunch of defect fixes.
So in that concept any .NET 4.x should be able to run any .NET application targetting 4.0 -> 4.x. If you just want security patches they knock yourself out with 4.0 SP1 or whatever.
We make a commercial product and accordingly I live in fear of anything that's not "in the box" on the basic framework unless I have absolute confidence there's a way we can explain it and target it. In many ways .NET 4.0 was great simply because we didn't have to explain to people how to get to .NET 3.5 SP1. Now we're not touching any of the EF changes etc. because it'll make our life harder to explain to customers what they need to install & target. It'd be a lot easier to say ".NET 4.1". That they would get. Oh, and have a slipstreamed install of it. Seriously - did anyone have fun installing .NET 3.5SP1 where each incremental package was larger than the thing it was patching? Good times.
So in that concept any .NET 4.x should be able to run any .NET application targetting 4.0 -> 4.x. If you just want security patches they knock yourself out with 4.0 SP1 or whatever.
We make a commercial product and accordingly I live in fear of anything that's not "in the box" on the basic framework unless I have absolute confidence there's a way we can explain it and target it. In many ways .NET 4.0 was great simply because we didn't have to explain to people how to get to .NET 3.5 SP1. Now we're not touching any of the EF changes etc. because it'll make our life harder to explain to customers what they need to install & target. It'd be a lot easier to say ".NET 4.1". That they would get. Oh, and have a slipstreamed install of it. Seriously - did anyone have fun installing .NET 3.5SP1 where each incremental package was larger than the thing it was patching? Good times.
Just keep it consistent.
I think we can all agree that the ".NET 3.0 and .NET 3.5 run on the CLR from .NET 2.0 ... but .NET 4.0 is a real big one ... and 90% of us can ignore that .NET 4.0 PU1 thing which is actually like an SP1 ... but not quite as big as an SP because we really had just released 4.0 ... so we made up PU1 for political reasons so it would sound less serious ... btw the whole PU1 thing demonstrates that it is impossible to rapidly iterate the WinFX libraries due to the deployment model ... too bad we didn't invent Nuget back in 2006 LOL" debacle should have never happened. I suppose that now that .NET is around 10 years old we would hit the "Java 2 SE 1.6.0 Update 26 build 3" nonsense eventually, and we sure did.
What is annoying is that there is a "real" major.minor.revision number in there somewhere -- just look in C:\Windows\Microsoft.NET\Framework. I don't know why we can't just use those.
I think we can all agree that the ".NET 3.0 and .NET 3.5 run on the CLR from .NET 2.0 ... but .NET 4.0 is a real big one ... and 90% of us can ignore that .NET 4.0 PU1 thing which is actually like an SP1 ... but not quite as big as an SP because we really had just released 4.0 ... so we made up PU1 for political reasons so it would sound less serious ... btw the whole PU1 thing demonstrates that it is impossible to rapidly iterate the WinFX libraries due to the deployment model ... too bad we didn't invent Nuget back in 2006 LOL" debacle should have never happened. I suppose that now that .NET is around 10 years old we would hit the "Java 2 SE 1.6.0 Update 26 build 3" nonsense eventually, and we sure did.
What is annoying is that there is a "real" major.minor.revision number in there somewhere -- just look in C:\Windows\Microsoft.NET\Framework. I don't know why we can't just use those.
I can understand how marketing people might try to be as descriptive as possible. But when marketing to developers, 4.2.2 is the most descriptive way for me. If I want to see whats hanged i'll read the readme.
I agree with semantic versioning/consistent versioning.
God is in the details.
God is in the details.
1) Agreed - go via the 4.0, 4.01, 4.02, etc route. I definitely appreciate that adding new features can be at odds with a servicing strategy , especially if you're trying to avoid introducing new features when you deliver a security patch. Perhaps there's some compromise to be made here.
2) Make it obvious when major new value is delivered - 3.5 SP1 - should have been 3.6 (min).
3) Don't splinter the stack. The concept of one stop shopping for MS dependencies is very, very nice; EF 4.1 being out of band is not the direction I want to see more things go from MS. Make it easy for us to determine what prerequisites are missing at deploy time. Release .NET 4.1 with EF 4.1, the azure/WF updates, all security updates, etc.
4) Speaking of deployment - I know you're a big fan of NuGet - but that's not how enterprise software gets deployed to the desktop, xcopy deployment is only for very simple applications, WiX is not a replacement for the lack of innovation in MSI; smallestdotnet is nice for home users, but that's about it.
5) Thanks for reaching out to the community to get our opinion.
2) Make it obvious when major new value is delivered - 3.5 SP1 - should have been 3.6 (min).
3) Don't splinter the stack. The concept of one stop shopping for MS dependencies is very, very nice; EF 4.1 being out of band is not the direction I want to see more things go from MS. Make it easy for us to determine what prerequisites are missing at deploy time. Release .NET 4.1 with EF 4.1, the azure/WF updates, all security updates, etc.
4) Speaking of deployment - I know you're a big fan of NuGet - but that's not how enterprise software gets deployed to the desktop, xcopy deployment is only for very simple applications, WiX is not a replacement for the lack of innovation in MSI; smallestdotnet is nice for home users, but that's about it.
5) Thanks for reaching out to the community to get our opinion.
The lack of consistent naming/versioning is annoying to me as a developer especially when i have to explain it to non-techinical managers. I frequently get asked whats the difference between 2.0 and 3.0, 3.0 and 3.5 since essenially 2.0 and 3.5 require different versions of the IDE while 2.0 and 3.0 use the same IDE just 3.0 enables WinFX …
Isn't it confusing?
.NET 3.5 = CLR 2.0 = C# 3.0
And there are people (interviewers) getting advantage to confuse interviewees.
Semantic Versioning rocks!
.NET 3.5 = CLR 2.0 = C# 3.0
And there are people (interviewers) getting advantage to confuse interviewees.
Semantic Versioning rocks!
Not just yes, but hell yes.
I think we'd all be shocked if we could put a dollar figure on the amount of time spent explaining the .NET Framework's versioning to managers, recruiters, server administrators, and even other developers.
I've not spoken with a anyone that said to me "Hey, I think the .NET Framework versioning makes perfect sense!" Almost, everyone has the same reaction which is more along the lines of "WTF?"
I think we'd all be shocked if we could put a dollar figure on the amount of time spent explaining the .NET Framework's versioning to managers, recruiters, server administrators, and even other developers.
I've not spoken with a anyone that said to me "Hey, I think the .NET Framework versioning makes perfect sense!" Almost, everyone has the same reaction which is more along the lines of "WTF?"
Hold on, but doesn't the assembly versions numbers change with each update? Maybe the problem is that MS should use the assembly version numbers on the marketing materials instead of trying to gloss over it with a "friendly" name.
I too agree, it really annoys me that MS does this. I strongly vote for Semantic Versioning. I believe it's because it's easier for MS to say we support 1.1 than to change/update that support statement/web page every time a point release is made....nevermind the confusion it places on us.
I have seen it worse that this example though...can't remember exactly, but it was something like "version x SP1 refresh update 2".
I have seen it worse that this example though...can't remember exactly, but it was something like "version x SP1 refresh update 2".
>> There isn't a technical reason that I know of to call something a Rollup Update Pack
In the open source java you would be headed for this. You would break maven (which is automatic recursive binary dependency tool, something meant to solve versioning hell). The only reason .NET does not use maven is because the framework releases are centralized and alligned. In Open Source world there are so many different projects updating in different timelines that you must have some tool that protects you from "DLL hell" (JAR hell). In order to specify version dependency you either state [4,0,1,1] or [4.0,) which means 4.0 or above. The notation is what drives everything
In the open source java you would be headed for this. You would break maven (which is automatic recursive binary dependency tool, something meant to solve versioning hell). The only reason .NET does not use maven is because the framework releases are centralized and alligned. In Open Source world there are so many different projects updating in different timelines that you must have some tool that protects you from "DLL hell" (JAR hell). In order to specify version dependency you either state [4,0,1,1] or [4.0,) which means 4.0 or above. The notation is what drives everything
I never knew Semantic Versioning was defined anywhere. I've had to convince every company I've worked at to use that versioning scheme. It's the only method that even makes sense in my mind.
.Net 3.0 was a laughable major version increment. Laughable.
.Net 3.0 was a laughable major version increment. Laughable.
I just don't see how anyone could argue AGAINST semantic versions. They just make sense. To say they confuse "the normals" is ridiculous. If people can understand dollars and cents, they can understand semantic versions.
+ 1 Semantic Versioning. Don't get me started on MS naming...
Yes to Semantic Versioning please!!!! Look at others, they have done away with minor or build revisions, every release is a 'new' release. Least we can do is follow the x.y.z versioning!!!
The versioning really does need to be extremely clear.
The one that annoyed me to no end was 3.5 vs 3.5 SP1.
That was the source of a lot of grief when I had to deal with certain clients.
You know the type: Major corporates who have outsourced IT departments who do exactly what's written down.
Someone asks the tech lead: "What's the server software requirements?"
Tech lead says "Windows 2008, IIS, .NET 3.5 SP1... " etc.
That gets put into the documentation as: "Windows 2008, IIS, .NET 3.5" because someone accidentally drops the SP1.
Client's tech team specifically drops .NET 3.5. on the server - nobody notices it because the things using the extra features in the SP are infrequently used. Random stuff breaks partway through testing.
After some significant time, you
Then ensues a week of arguing over whether we can deploy .NET 3.5 SP1, and who's to blame for this.
Forever more your first response to that feature breaking is "So, it's got .NET 3.5 SP1 deployed to the server, right?" which requires someone to RDP to the box (difficult, requires support tickets, etc) to ensure that was actually deployed. If there's a language difficulty between vendor and client's support/ops teams, well - this could take several days to verify.
The one that annoyed me to no end was 3.5 vs 3.5 SP1.
That was the source of a lot of grief when I had to deal with certain clients.
You know the type: Major corporates who have outsourced IT departments who do exactly what's written down.
Someone asks the tech lead: "What's the server software requirements?"
Tech lead says "Windows 2008, IIS, .NET 3.5 SP1... " etc.
That gets put into the documentation as: "Windows 2008, IIS, .NET 3.5" because someone accidentally drops the SP1.
Client's tech team specifically drops .NET 3.5. on the server - nobody notices it because the things using the extra features in the SP are infrequently used. Random stuff breaks partway through testing.
After some significant time, you
Then ensues a week of arguing over whether we can deploy .NET 3.5 SP1, and who's to blame for this.
Forever more your first response to that feature breaking is "So, it's got .NET 3.5 SP1 deployed to the server, right?" which requires someone to RDP to the box (difficult, requires support tickets, etc) to ensure that was actually deployed. If there's a language difficulty between vendor and client's support/ops teams, well - this could take several days to verify.
Totally agree. Should be 4.0, 4.1, 4.2 (or even minor versions etc). I go to microsoft.com/net and then click the download button, and have to install the 4.0 base, then let windows update tell me there are updates to it. Should be like everything else, Wordpress, jQuery etc, go to the download page, and th latest version is at the top ready to go (and stand alone as well - whats with this web installer rubbish? No servers in our organisation have direct access to the internet, so takes me even more time to find the stand alone and download that, then find all the updates and download them, and then install them all one after the other). Its just such a mess. Forget service packs, cumulative updates, feature enhancements. One version, everything in it, simple. </rant>
+1 and while you are at it perhaps you could get marketing to issue a complete historical timeline of all .NET releases (including add-ons and components like MVC, EF, WCF, ... ) as there doesn't seem to be a coherent, complete list anywhere.
I seriously have always wished that software version information should include the date of release apart from the major and minor version.
for e.g:
"Product Name :Major ver .minor version .[*date of release*].[CTP/SP/PU]
say , Entity Framework:4.1.1.07.2011.CTP which implies "Entity Framework versioned 4.1 , June 2011 CTP release"
Advantage : 1) All required info in one place.
2) Easily sortable , searchable and filterable .
Regards
Girija
for e.g:
"Product Name :Major ver .minor version .[*date of release*].[CTP/SP/PU]
say , Entity Framework:4.1.1.07.2011.CTP which implies "Entity Framework versioned 4.1 , June 2011 CTP release"
Advantage : 1) All required info in one place.
2) Easily sortable , searchable and filterable .
Regards
Girija
My blog post "What do CTP, RC, RTM, RTW mean?" where I compile all the MS build-related jargon gets a lot of hits for obvious reasons. I loved the historical timeline of the .NET Framework that you presented in a table & feel that all major products should have an official About/History page or a community wiki with an overview of the various versions.
On a different note, having a date of creation/modification in the formal documentation as in the MS KB articles can sometimes help in putting things in perspective with respect to versioning. It also disappoints me when links on official MS sites break.
On a different note, having a date of creation/modification in the formal documentation as in the MS KB articles can sometimes help in putting things in perspective with respect to versioning. It also disappoints me when links on official MS sites break.
This is especially frustrating when you can't quickly look at a production machine and know which version of the framework is on it and whether or not the new features you are using are available on that machine.
Oh, and BTW, we don't like it when you introduce big changes in a "service pack" like what happened in 3.5SP1.
Our company has to maintain a list of approved technology and a roadmap of when old tech is no longer allowed. That is really difficult with naming like this. It's impossible to say .Net 2.0 is no longer permitted and 3.0 or 3.5 or 3.5SP1 is, since it requires 2.0. Again, not easy to explain to those who don't follow this stuff closely.
Our company has to maintain a list of approved technology and a roadmap of when old tech is no longer allowed. That is really difficult with naming like this. It's impossible to say .Net 2.0 is no longer permitted and 3.0 or 3.5 or 3.5SP1 is, since it requires 2.0. Again, not easy to explain to those who don't follow this stuff closely.
New languages (F#), new language features (LINQ, async/await, etc.), and significant behavioral changes to the CLR/DLR should follow to the Visual Studio release schedule. These should be major version number releases for new VS editions (i.e., VS2012=.NET 5, VS2014=.NET 6) with possible point releases following the schedule for VS service packs.
My hope with NuGet is that eventually all of the auxiliary features of the framework will evolve out-of-band, taking on their own versioning schemes. I think this is critically important for 2 reasons. First, it allows MS DevDiv to be more agile and to react quickly to emerging technologies that live outside of MS' control (e.g., HTML5, HTML5/WebSockets). More importantly, I think the quicker release cycle on the individual components (EF, WCF, MVC, etc.) enables the developers to engage with the developer community much more effectively.
If I want to see a new feature or a bug fixed in VS 2012, I'll go to Microsoft Connect. I'll submit a ticket and then forget about it. Hopefully I'll be pleasantly surprised one day if it gets fixed/implemented. I understand the amount of work that goes into reacting to suggestions in a lifecycle that involves language translations, SKU/licensing, legal, CD/ISO distribution, etc.. On the other hand, if I want to see a new feature or get a bug fixed in EF, I'll go to CodePlex and engage directly with the developers and the other users who have a stake in the technology. Not only are the odds of good ideas being implemented higher, but the timeline is much shorter. This is a win-win for everyone.
In a perfect world, I buy one of the TWO editions of VS2012 (Basic or Pro... TWO!!!) that fits my needs. The VS installer kicks off the .NET Framework 5 Installer (not 4.5 SP2). It installs the compilers, config, and core features of the framework. Everything else is modular, optional, and a la carte (think Web Platform Installer). In offline installer mode, the modules can be included and installed via NuGet from a repository on the VS2012 disc/ISO. In the web installer, NuGet can build and maintain local framework-specific repository of MS-built .NET features from the web. This would include things like EF, WCF, WF, MVC, etc.
My hope with NuGet is that eventually all of the auxiliary features of the framework will evolve out-of-band, taking on their own versioning schemes. I think this is critically important for 2 reasons. First, it allows MS DevDiv to be more agile and to react quickly to emerging technologies that live outside of MS' control (e.g., HTML5, HTML5/WebSockets). More importantly, I think the quicker release cycle on the individual components (EF, WCF, MVC, etc.) enables the developers to engage with the developer community much more effectively.
If I want to see a new feature or a bug fixed in VS 2012, I'll go to Microsoft Connect. I'll submit a ticket and then forget about it. Hopefully I'll be pleasantly surprised one day if it gets fixed/implemented. I understand the amount of work that goes into reacting to suggestions in a lifecycle that involves language translations, SKU/licensing, legal, CD/ISO distribution, etc.. On the other hand, if I want to see a new feature or get a bug fixed in EF, I'll go to CodePlex and engage directly with the developers and the other users who have a stake in the technology. Not only are the odds of good ideas being implemented higher, but the timeline is much shorter. This is a win-win for everyone.
In a perfect world, I buy one of the TWO editions of VS2012 (Basic or Pro... TWO!!!) that fits my needs. The VS installer kicks off the .NET Framework 5 Installer (not 4.5 SP2). It installs the compilers, config, and core features of the framework. Everything else is modular, optional, and a la carte (think Web Platform Installer). In offline installer mode, the modules can be included and installed via NuGet from a repository on the VS2012 disc/ISO. In the web installer, NuGet can build and maintain local framework-specific repository of MS-built .NET features from the web. This would include things like EF, WCF, WF, MVC, etc.
Windows 7 Premium is actually Windows 7 Home Premium. I assume they slapped Premium in there to differentiate it from Windows 7 Home Basic, the edition for emerging markets.
But I completely agree with you. Microsoft, especially as of late, is coming up with great innovation and new technologies, but they're still naming their products like it is 1995.
This reminds me of Microsoft Windows Vista Ultimate UPGRADE Limited Numbered Signature Edition.
But I completely agree with you. Microsoft, especially as of late, is coming up with great innovation and new technologies, but they're still naming their products like it is 1995.
This reminds me of Microsoft Windows Vista Ultimate UPGRADE Limited Numbered Signature Edition.
Totally agree. Trying to figure out the different versioning of things (and wade through some of the acronym soup) can become quite confusing. I agree with Daniel liuzzi - MS is doing some cool things of late. But they should apply some of those marketing dollars to designing a straighforward and consistent version identification model across their product line.
Oh, and I totally agree and second the comments by others with respect to assumed compatibility between minor version updates. Version 4.x should not break code which is based on 4.0, and anything written with version 4.x shoudl be backward compatible to at least 4.0 (in other words, the interfaces should remain consistent). Anything written to be compatible with major version 4 should work with version 4.x and vice versa (except to the extent that 4.x fixes a bug present in 4.x - 1, but that's different).
Oh, and I totally agree and second the comments by others with respect to assumed compatibility between minor version updates. Version 4.x should not break code which is based on 4.0, and anything written with version 4.x shoudl be backward compatible to at least 4.0 (in other words, the interfaces should remain consistent). Anything written to be compatible with major version 4 should work with version 4.x and vice versa (except to the extent that 4.x fixes a bug present in 4.x - 1, but that's different).
Well there are two parts to this story en both have a primarily different kind of public. The first group is the average Windows/Office user. These product are released for the mainstream user and they don't really care about version numbers as long they have the latest version.
The second group is the development community and a large part has it's root in unix/linux programming. From the early days there's a defacto standard for version numbers in the form of x.y.z (build numbers aren't often used). X is the major version and when updated could break compatibility with previous versions. Y verion updates are large improvements and new features and everything should still work the same (like .NET 3.0 vs 3.5). Z updates are commonly seen as security and bugfix updates. And while this version schema held up pretty long, there seems to be a rage to crank up the major version numbers. Google really kick-start this with the Chrome browser and not long after also Firefox was following this schema.
To my humble opinion every tool/utility/framework that's related to the development field should have a predictable version number.
The second group is the development community and a large part has it's root in unix/linux programming. From the early days there's a defacto standard for version numbers in the form of x.y.z (build numbers aren't often used). X is the major version and when updated could break compatibility with previous versions. Y verion updates are large improvements and new features and everything should still work the same (like .NET 3.0 vs 3.5). Z updates are commonly seen as security and bugfix updates. And while this version schema held up pretty long, there seems to be a rage to crank up the major version numbers. Google really kick-start this with the Chrome browser and not long after also Firefox was following this schema.
To my humble opinion every tool/utility/framework that's related to the development field should have a predictable version number.
Absolutely. Perhaps use major versions to indicate massive changes such as a CLR update, minor to be libraries only and revision to be just revisions.
This probably would have made more sense:
1.0 -> 1.0.0
1.1 -> 2.0.0
2.0 -> 3.0.0
3.0 -> 3.5.0
3.5 -> 3.10.0
3.5 SP1 -> 3.15.0
4.0 -> 4.0.0
4.0 PU1 -> 4.0.1
Nice thing about using CLR in the major revision is you instantly know what will break. Minor revisions give you an idea of things likely to break as well.
This probably would have made more sense:
1.0 -> 1.0.0
1.1 -> 2.0.0
2.0 -> 3.0.0
3.0 -> 3.5.0
3.5 -> 3.10.0
3.5 SP1 -> 3.15.0
4.0 -> 4.0.0
4.0 PU1 -> 4.0.1
Nice thing about using CLR in the major revision is you instantly know what will break. Minor revisions give you an idea of things likely to break as well.
I agree that it is getting confusing to a point that I can no longer follow.
The key thing for Microsoft to do here is to have a single, company wide version story. I'd start with just basic version numbers and the only thing I'd add is specific patches in the form of kb packages. As long as they are well documented they work great.
And one other thing should stay. Beta is still something I'd keep.
You don't need named new versions, not even SP's. I don't care if someone has installed all the Windows updates on a system right up to SP1 or if they have SP1 installed. It should be the same thing. The only thing that should change with updates through Windows Update is that they should not keep me waiting for more than two minutes when shutting down my laptop. If that was fixed I'd be happy to update every other day if that is what it takes. Just don't make me watch it and get it over with.
The key thing for Microsoft to do here is to have a single, company wide version story. I'd start with just basic version numbers and the only thing I'd add is specific patches in the form of kb packages. As long as they are well documented they work great.
And one other thing should stay. Beta is still something I'd keep.
You don't need named new versions, not even SP's. I don't care if someone has installed all the Windows updates on a system right up to SP1 or if they have SP1 installed. It should be the same thing. The only thing that should change with updates through Windows Update is that they should not keep me waiting for more than two minutes when shutting down my laptop. If that was fixed I'd be happy to update every other day if that is what it takes. Just don't make me watch it and get it over with.
@Scott (http://www.sholo.net/)
That's what I had in mind too: Use Nuget to install most of the components
In a perfect world, I buy one of the TWO editions of VS2012 (Basic or Pro... TWO!!!) that fits my needs. The VS installer kicks off the .NET Framework 5 Installer (not 4.5 SP2). It installs the compilers, config, and core features of the framework. Everything else is modular, optional, and a la carte (think Web Platform Installer). In offline installer mode, the modules can be included and installed via NuGet from a repository on the VS2012 disc/ISO. In the web installer, NuGet can build and maintain local framework-specific repository of MS-built .NET features from the web. This would include things like EF, WCF, WF, MVC, etc
That's what I had in mind too: Use Nuget to install most of the components
The next version of .Net framework will be 4.0 September CTP R2 update magic unicorn edition!
Totally agree about semantic versioning! only digits please! You can see the amount of changes between versions by looking at the version number.
Totally agree about semantic versioning! only digits please! You can see the amount of changes between versions by looking at the version number.
Symantic versioning. We do care. We're programmers. We love our numbers. It makes me sad that such great products as .NET and The CLR, has such a "bad" face because of the versioning. What I think is even worse than "Update 1" and stuff like that is "You need Framework version 2.0.209584". Semantic versioning, and keep it simple. MICROSOFT, HEAR US!
I'm for Semantic Versioning all the way. Semantic Versioning (4.0, 4.1, 4.1.1, ...) must be mandatory and beside this there can be also some name (SP1, Update 3, ...) or nickname ("magic cheese edition", ...) if team like it that way.
Also synchronization between product (if they bundled or released together) is very important. All peieces (EF, ASP.NET MVC, Windows Forms, ...) released as .NET Framework 4.0 should have version 4.0. Then updates can come as teams works, but when there will be version 4.1 ("4.0 SP1"), then all pices must upgrade to version 4.1 even if there is no change in functionality or no change at all.
just my $.02
s.
Also synchronization between product (if they bundled or released together) is very important. All peieces (EF, ASP.NET MVC, Windows Forms, ...) released as .NET Framework 4.0 should have version 4.0. Then updates can come as teams works, but when there will be version 4.1 ("4.0 SP1"), then all pices must upgrade to version 4.1 even if there is no change in functionality or no change at all.
just my $.02
s.
Yes yes yes! As the comments here show, not only are there multiple pain points with the current "system" (if that isn't overstating the level of organisation there currently is!), there is not one single upside to the way things are.
+1 to whoever said convention over confusion and to this whole semantic versioning concept.
+1 to whoever said convention over confusion and to this whole semantic versioning concept.
I think they should use only semantic versioning for products, who are meant for technical people - like all server products, dev products etc, and use whatever they want (+ semantic version) for products meant for home users. For example .NET should be versioned 4.0, 4.1, 4.1.2, 5.0 etc, and the next release of Windows 7 can say "Windows 7 Really Awesome update 20" on the box (if the marketing people thing it'll sell better), but have a normal semantic version Microsoft Windows NT 6.2.
And the inconsistency with SKU names is just a f*** up from the naming perspective IMO, SKU names should be descriptive, not confusing.
And the inconsistency with SKU names is just a f*** up from the naming perspective IMO, SKU names should be descriptive, not confusing.
+1 gazillion for semantic versioning.
It is the first step in getting the .Net eco-system back on some tracks. Currently it seems there are many teams going (doing) agile at microsoft, but each is going on its own seperate path, and not communicating enough with the other teams. Ctp's, updates, refreshes, sp's, they are all flying around our ears. It has become extremely hard to keep track of where which technology is at. So versioning the stuff is critical and one of the first steps needed to get .Net back on its rails (pun?).
I really like Berts comment linking to just give us smaller nuget pieces not big frameworks How I would like Microsoft to distribute .NET v.Next but for MS to achieve that, we need a clear versioning story, if not were are all going to package hell. (It is already starting to feel this way now.) Scott, our saviour ;-)
It is the first step in getting the .Net eco-system back on some tracks. Currently it seems there are many teams going (doing) agile at microsoft, but each is going on its own seperate path, and not communicating enough with the other teams. Ctp's, updates, refreshes, sp's, they are all flying around our ears. It has become extremely hard to keep track of where which technology is at. So versioning the stuff is critical and one of the first steps needed to get .Net back on its rails (pun?).
I really like Berts comment linking to just give us smaller nuget pieces not big frameworks How I would like Microsoft to distribute .NET v.Next but for MS to achieve that, we need a clear versioning story, if not were are all going to package hell. (It is already starting to feel this way now.) Scott, our saviour ;-)
The real problem with semantic versioning for something like the .NET framework is there are so many hundreds of components .... semantic versioning loses its meaning.
For example, the fact they added Azure support in 4.0 PU1 does that means there are no breaking or major changes?
- Well yes perhaps they are major or breaking with regards to Azure
- But that doesnt tell you if Workflow has major or breaking changes or just bug fixes
How can a huge framework be versioned under a single semantic versioning system?
I am all for semantic versioning but the real problem here lies in a huge monolithic approach to framework distribution.
For example, the fact they added Azure support in 4.0 PU1 does that means there are no breaking or major changes?
- Well yes perhaps they are major or breaking with regards to Azure
- But that doesnt tell you if Workflow has major or breaking changes or just bug fixes
How can a huge framework be versioned under a single semantic versioning system?
I am all for semantic versioning but the real problem here lies in a huge monolithic approach to framework distribution.
+1 semantic versioning!!!
However, Scott, you write at the end of this blog post with regards to EF 4.1 Update 1, that "I would have said 4.1.5 or 4.2. Probably 4.2 if there were minor new features, and 4.1.5 if it's just patches."
Why would you want to just from vertion 4.1(.0) to 4.1.5? These .5 version jumps drive my crazy - it's like saying: "We're made to changes - they're not minor, but not major either".
What happens when you make the same amount changes to 4.1.5? Do we then jump to 4.1.10? And what happens if we in between added some minor changes to 4.1.5, so that it's now 4.1.6 - should the next "not minor, not major" changes jump to 4.1.11?
If you want semantic versioning - go all the way! From 4.1 there's three and only three options: 4.1.1, 4.2 or 5.0
However, Scott, you write at the end of this blog post with regards to EF 4.1 Update 1, that "I would have said 4.1.5 or 4.2. Probably 4.2 if there were minor new features, and 4.1.5 if it's just patches."
Why would you want to just from vertion 4.1(.0) to 4.1.5? These .5 version jumps drive my crazy - it's like saying: "We're made to changes - they're not minor, but not major either".
What happens when you make the same amount changes to 4.1.5? Do we then jump to 4.1.10? And what happens if we in between added some minor changes to 4.1.5, so that it's now 4.1.6 - should the next "not minor, not major" changes jump to 4.1.11?
If you want semantic versioning - go all the way! From 4.1 there's three and only three options: 4.1.1, 4.2 or 5.0
How do I detect the new version?
If I've taken a dependency on the new EF 4.1 in .net4.1 - how do I detect this during a deployment?
Is .net4.1 installed in \windows\Microsoft.net\Framework\v4.0.30319 or is it in \windows\Microsoft.net\Framework\v4.1.34374 ?
Is a new key going to show up under HKLM\Software\Microsoft\NET Framework Setup\NDP\v4 ?
The bucket that is shipped as .net is too big: the Framework should be one version, and all the barnacles that glommed on during .net 3.0 and 3.5 should be hived off into separate packages - this seems to be working well for ASP.NET MVC. There's no reason EF, WF, WPF, WCF couldn't also live separate lives from the core framework.
+1 SEMVER and +1 SUNDERING (Split the monolith into smaller pieces)
If I've taken a dependency on the new EF 4.1 in .net4.1 - how do I detect this during a deployment?
Is .net4.1 installed in \windows\Microsoft.net\Framework\v4.0.30319 or is it in \windows\Microsoft.net\Framework\v4.1.34374 ?
Is a new key going to show up under HKLM\Software\Microsoft\NET Framework Setup\NDP\v4 ?
The bucket that is shipped as .net is too big: the Framework should be one version, and all the barnacles that glommed on during .net 3.0 and 3.5 should be hived off into separate packages - this seems to be working well for ASP.NET MVC. There's no reason EF, WF, WPF, WCF couldn't also live separate lives from the core framework.
+1 SEMVER and +1 SUNDERING (Split the monolith into smaller pieces)
Microsoft always offer updates - Apple offer fluffyness. Updates imply that something was wrong with the inital product.
Whereas a Lion as much better than a leopard, its not that leopards are faulty, its just that Lions are more ROAARRR!
If Windows XP service pack 3 was called fluffy snow donkey, people would embrace it more fully.
Whereas a Lion as much better than a leopard, its not that leopards are faulty, its just that Lions are more ROAARRR!
If Windows XP service pack 3 was called fluffy snow donkey, people would embrace it more fully.
Good on you for championing this, Scott. Production software going out with arbitrary version naming is a nonsense, and for a company like Microsoft to be doing it boggles the mind. What is the point of having a Version object with Major, Minor, Build and Revision integer properties if you're going to call things 4.New.Improved?
If Microsoft teams adopted proper semantic versioning during internal development cycles, so internal builds were called things like 8.0.0alpha17, we could even get to a point where brand new software landed with the version number 8.0.0! And then Service Pack 1 could be 8.1.0! Imagine the clarity!
"You may say that I'm a dreamer, but I'm not." ~ Barry, Dinner for Schmucks.
If Microsoft teams adopted proper semantic versioning during internal development cycles, so internal builds were called things like 8.0.0alpha17, we could even get to a point where brand new software landed with the version number 8.0.0! And then Service Pack 1 could be 8.1.0! Imagine the clarity!
"You may say that I'm a dreamer, but I'm not." ~ Barry, Dinner for Schmucks.
I agree and you certainly get my vote for Semantic Versioning.
If you need more arguments for transparent versioning schemes, I'd like to recommend Luke Hohmann's book Beyond Software Architecture.
If you need more arguments for transparent versioning schemes, I'd like to recommend Luke Hohmann's book Beyond Software Architecture.
I don't like the "EF 4.1 Update 1" name. It should have been called "EF 4.2". Simple.
For this "update" to EF, it has introduced some new types (namely, DbContextInfo and IDbContextFactory<>) - for me, this means it's not just a "patch", but has introduced something new (albeit a minor thing) so therefore it gets a new (minor) version number, hence EF 4.2.
I think this all started for Microsoft with the release of .NET Framework 3.5 Service Pack 1.
Up until that point, I'd always believed (because I'm sure I read it somewhere) that Service Packs do NOT introduce new functionality. They fix bugs, or tidy up features that already exist, but they don't deliver new functionality. If you have new functionality to deliver, you have a new version number. So that's a new minor version number if the new functionality or additions are relatively small, and a new major version number if the changes are big (like introducing whole new frameworks/technologies).
I think MS screwed up the versioning on .NET 3.5 SP1 because they'd already released 3.5, and they seem incredibly reluctant to utilse any minor version number other than 0 or 5! Seems they didn't want to call it 4.0 as it wasn't accompanied by a new version of Visual Studio, so they had to bastardize the "Service Pack" moniker for the wrong purposes!
For this "update" to EF, it has introduced some new types (namely, DbContextInfo and IDbContextFactory<>) - for me, this means it's not just a "patch", but has introduced something new (albeit a minor thing) so therefore it gets a new (minor) version number, hence EF 4.2.
I think this all started for Microsoft with the release of .NET Framework 3.5 Service Pack 1.
Up until that point, I'd always believed (because I'm sure I read it somewhere) that Service Packs do NOT introduce new functionality. They fix bugs, or tidy up features that already exist, but they don't deliver new functionality. If you have new functionality to deliver, you have a new version number. So that's a new minor version number if the new functionality or additions are relatively small, and a new major version number if the changes are big (like introducing whole new frameworks/technologies).
I think MS screwed up the versioning on .NET 3.5 SP1 because they'd already released 3.5, and they seem incredibly reluctant to utilse any minor version number other than 0 or 5! Seems they didn't want to call it 4.0 as it wasn't accompanied by a new version of Visual Studio, so they had to bastardize the "Service Pack" moniker for the wrong purposes!
I agree, something needs to be done.
I don't have time to read all the comments but I think:
- Make the installer filename contain the version too, e.g. EntityFramework-4.1.1.exe
- Always refer to products which have a service pack baked in as "Product X with SP1" not "Product X SP1"
- Stop being marketing led and think about what makes sense to developers and IT Professionals
I don't have time to read all the comments but I think:
- Make the installer filename contain the version too, e.g. EntityFramework-4.1.1.exe
- Always refer to products which have a service pack baked in as "Product X with SP1" not "Product X SP1"
- Stop being marketing led and think about what makes sense to developers and IT Professionals
Definately, I for one would prefer Semantic Versioning rather than random Update, Service Release, Service Pack. There is hope that Microsoft can do this - I noticed that the recent update to IE 9 bumped the version to 9.0.1.
I'd also like to see the end of .5 releases also - just increase the minor version by one as you add functionality (there can be more than 10 minor versions - so why use .5!??)
I'd also like to see the end of .5 releases also - just increase the minor version by one as you add functionality (there can be more than 10 minor versions - so why use .5!??)
@Zack Peterson
As someone who has built Windows Mobile applications for exactly that purpose (a ruggedized warehouse barcode scanner), my best advice is to break from the Microsoft platform here; it's a mess and Microsoft management is too distracted with Windows Phone and an internal DevDiv/WinDev war:
https://connect.microsoft.com/VisualStudio/feedback/details/595712/no-support-for-windows-ce-and-compact-framework-development-in-vs2010
As someone who has built Windows Mobile applications for exactly that purpose (a ruggedized warehouse barcode scanner), my best advice is to break from the Microsoft platform here; it's a mess and Microsoft management is too distracted with Windows Phone and an internal DevDiv/WinDev war:
https://connect.microsoft.com/VisualStudio/feedback/details/595712/no-support-for-windows-ce-and-compact-framework-development-in-vs2010
"I find it really frustrating when they have various "names" for the versions of the same product. "
Pretty much this. Ordinarily its not a big deal, but it can be a hassle if you're trying to make sure two environments are the same.
Pretty much this. Ordinarily its not a big deal, but it can be a hassle if you're trying to make sure two environments are the same.
I really believe that version numbers should tell you something about the product. And, what I want to know is "when did this come out?" and "what has changed?". While a version number can imply a relative scope of the change, they really can't tell me what actually changed. However, they can tell you when this change occured.
Instead of calling it version "4 Platform Update 1" they could have called it version "4.1.1104". From this I know that the scope of the change overall is fairly small and there should be no breaking changes because they didn't change the major version number. And, I know that this change is from April 2011 because the last number is formmated as YYMM.
Instead of calling it version "4 Platform Update 1" they could have called it version "4.1.1104". From this I know that the scope of the change overall is fairly small and there should be no breaking changes because they didn't change the major version number. And, I know that this change is from April 2011 because the last number is formmated as YYMM.
By the way ... EF and .Net are not the worst example of this by far. The WORST is Silverlight RIA Services, or is it Astoria ... no wait that was a different product. I think it was WCF RIA ODATA. No, no ... it's Silverlight WCF Astoria ODATA RIA Serivces, right?
I give up.
I give up.
Couldn't agree more. Semantic Versioning FTW. We don't need a new product name (or surname) for each release. Let's stick to product name and a compreensive version number.
Semantic Versioning makes things so much clearer. Windows is another culprit
- numbers (3.1)
- years (98)
- names (XP,Vista)
- back to numbers (7)
Then there's SP and now Update..........no wonder it get's confusing.
- numbers (3.1)
- years (98)
- names (XP,Vista)
- back to numbers (7)
Then there's SP and now Update..........no wonder it get's confusing.
@jmccliment.myopenid.com - "Trying to understand why 4.1 Enterprise Rainbow Sprinkles Hotfix Rollup with Jam is more current than 4.1 Premium Chocolate Sauce Ramalamadingdong is impossible."
+1 for humor.
+1 for sarcasm.
+1 for delivery.
+1 for putting in a loop, posting to youtube, and sending the link to the marketing department.
+1 for humor.
+1 for sarcasm.
+1 for delivery.
+1 for putting in a loop, posting to youtube, and sending the link to the marketing department.
I voted for Semantic Versioning. But if MS decides to keep going with words I suggest hiring a paint company to come up with names. I've never seen such evocative names for shades of grey. From the Behr website: "Broadway", "Mined Coal", "Manuscript", "Pier", "Dried basil".
This is most definitely confusing and permeates through all the Microsoft products. SharePoint is a horrible offender and results in blog posts like this one in order for people to keep the version numbers straight. What's the difference between an infrastructure update and a cumulative update? When you ask someone what version they are on sometimes they will say "the June Cumulative Update". There are actually multiple June CU's which means in order to know for sure you have to say the year and the month which gets confusing fast. Whenever you want to find out what version someone is running you need to find the version number then refer to a blog post to find out which CU they are on...not a great way to do things IMHO.
Completely agree. Versioning is important and should be intuitive, not a stream of code words or qualifiers. Comment 5.4 SP3 Update 78 A
Hi Scott,
Thanks for taking up this issue. I hope the feedback you gather is heard by TBTB. I would *love* it if Microsoft could coordinate, simplify and make consistent the version names of its products (and product names for that matter, but that's a different fight). If version names were easier for me to understand it would all allow me free up some brain cycles that I could put to better use on my projects.
Thanks for taking up this issue. I hope the feedback you gather is heard by TBTB. I would *love* it if Microsoft could coordinate, simplify and make consistent the version names of its products (and product names for that matter, but that's a different fight). If version names were easier for me to understand it would all allow me free up some brain cycles that I could put to better use on my projects.
Semantic Version FTW!!!! Its hard enough at the moment without explaining what changes are in the update and if they're minor...blah blah blah
Definitely agree with this... Regardless of whether or not they do Semantic Versioning or not, inconsistency in version naming is difficult to deal with and leads to a lot of confusion.
> perhaps you could get marketing to issue a complete historical timeline of all .NET releases
>> Ian - Maybe we can put up a wiki and do it ourselves?
While a wiki would be great, I think it could be a teaching moment to make the people who caused it gather the info. Once they get to ".net 3.5 sp1 compat with clr2, c#3: contains new features such that apps targeting this can not run on .net 3.5".... well, perhaps somebody may say "why do we make this so *hard*?"
YES!!!
I could go on and on Microsoft makes some great stuff but the naming and versioning gets really badly done at times!
I could go on and on Microsoft makes some great stuff but the naming and versioning gets really badly done at times!
First off, awesome post. Second off I have no clue when I see the word "Update" of what that means. Is an update bug fixes? Is it new functionality? It is utterly meaningless. I agree with your versioning scheme. It makes sense, I know what to expect when I see it and it's simple.
Another example of odd numbering: Windows Phone 7.1 or 7.5 or both? hmm, odd... (Either way, I'm excited to get it)
http://anythingbutiphone.com/6502
Dan in Vancouver
http://anythingbutiphone.com/6502
Dan in Vancouver
I don't think end users really care whether the CLR has versioned or whether you've just added some fancy new libraries. What they care about is 'do I meet the requirements to run this app.' For example, my app requires .NET 4.0 or requires .NET 3.5 SP1. Note that .NET 4.0 is much nicer than .NET 3.5 SP1.
I also agree 100% on silly naming like professional, premier, ultimate, etc. How about VS 2010 infinity time infinity edition? Even a "Good, Better, Best" name would make it clear which one was the big box.
I also agree 100% on silly naming like professional, premier, ultimate, etc. How about VS 2010 infinity time infinity edition? Even a "Good, Better, Best" name would make it clear which one was the big box.
Couldn't agree more with you! stick to the basics; semantic versioning makes everybody's life easier.
Cheers,
Abe
Cheers,
Abe
For the love of Turing, YES!! Yes, semantic versioning should be used, and YES it is important!
I can't even say I hate the system that is being used now for .NET, because as far as I can tell it isn't a system, which is even worse. But it has to change. I remember commenting on your blog when 3.5 SP1 was released about the utter ridiculousness of 2.0-3.0-3.5-3.5 SP1. It's even worse when something that is called a Service Pack is NOT a service pack. And seriously, "Platform Update"??
We have to fight enough battles on a daily basis with regards to figuring out what version of what product we need and how to get it deployed to our users. Please, please use whatever influence you have to convince whoever is making these insane decisions that they are doing their customers a massive disservice by making it even more difficult for us with their naming choices.
I can't even say I hate the system that is being used now for .NET, because as far as I can tell it isn't a system, which is even worse. But it has to change. I remember commenting on your blog when 3.5 SP1 was released about the utter ridiculousness of 2.0-3.0-3.5-3.5 SP1. It's even worse when something that is called a Service Pack is NOT a service pack. And seriously, "Platform Update"??
We have to fight enough battles on a daily basis with regards to figuring out what version of what product we need and how to get it deployed to our users. Please, please use whatever influence you have to convince whoever is making these insane decisions that they are doing their customers a massive disservice by making it even more difficult for us with their naming choices.
Great post, Scott. Here's my little contribution: http://blogs.msdn.com/b/kirillosenkov/archive/2011/07/28/how-microsoft-names-releases-and-what-you-can-do-about-it.aspx
Microsoft® SQL Server® 2008 R2 SP1 Feature Pack CTP1.
Microsoft® SQL Server® 2008 R2 SP1 Feature Pack CTP1.
Also, +1 for the idea of creating a wiki with the entire release history of all major .NET related components. It is ridiculous that we have to do this ourselves instead of Microsoft (who actually did the releases and has direct access to all of the release information) providing it to us. But if they won't, then we should.
Semantic please! Definitely would help a lot to drop stupid names like "service pack", "power pack", "turbo jet pack", " nu pack", "Update 1", "R2", etc.. are just confusing at times.
Not only on dev tools, but also in product like Windows, where is Home Basic, Home Premium, blah blah blah. People end up buying computer for their small offices in Office Max, they see a cheap one and end up buying Home Basic (because they don't know the damn difference) which they keep having issues with on their networks and just get frustrated with Windows and the Microsoft brand. They should just release Windows and Windows Enterprise if all they care is get the extra cash when selling to enterprises.
Not only on dev tools, but also in product like Windows, where is Home Basic, Home Premium, blah blah blah. People end up buying computer for their small offices in Office Max, they see a cheap one and end up buying Home Basic (because they don't know the damn difference) which they keep having issues with on their networks and just get frustrated with Windows and the Microsoft brand. They should just release Windows and Windows Enterprise if all they care is get the extra cash when selling to enterprises.
I think the poor naming choices is one of the major things that completely destroys Microsoft consumer awareness and understanding of products. It even impacts the more technical people, it is much easier for me to remember 4.01, than .NET 4.0 Update Release 1, or .NET 4.0 Update Release 1 Service Release 1, I mean what would they call an update to Update Release 1? In any effect this completely destroys their branding, but it goes further than versioning, much further. Microsoft has an awful habbit of tacking their name onto products, and also using more than one word as the name of their product! This makes their consumer marketing very difficult if not impossible, most time time consumers refer to Microsoft Word as just Word, or the whole suite Microsoft Office as just Office. No one cares that you made it, seriously, we don't! Nor should we care, Apple has far surpassed you without putting 'Apple' in front of their name in name brand recognition but also in revenues, and success! Also the multiple SKU thing is a joke, IMO if Microsoft releases Windows 8 with more than 2 SKU's, including the Server OS it will be the worst selling Microsoft Operating System in history. Hell most non-tech people I talk to think Office IS Windows!
I couldn't agree more. Semantic versioning is the best possible solution especially with all of the out-of-band releases, tool updates, feature updates out there (and coming). It has gotten so bad for me that now when I need to set up a new box for a new developer with "everything you need to build and work on our stuff" I have a series of numbered folders with patches, service packs, etc. It would be so much easier to simply install a 4.2.2 update (or whatever is latest) and KNOW that within that I get MVC3 tools update along with EF code first along with X and Y and whatever else we need. An update to a product (VS or .NET) should be an update to the product and reflected in the version number... period!
BTW... SQL server doesn't escape this nightmare either. You can't install 2008 SP2 on an R2 box but the new R2 SP1 is LATER than SP2? Isn't that nice and clear.
And here I thought that .NET side-by-side was supposed to get rid of dependency hell! No so much.
BTW... SQL server doesn't escape this nightmare either. You can't install 2008 SP2 on an R2 box but the new R2 SP1 is LATER than SP2? Isn't that nice and clear.
And here I thought that .NET side-by-side was supposed to get rid of dependency hell! No so much.
The "rollup" designation originally came from the idea that they would aggregate a large number of hot fixes and "roll them up" into a single update. So that one actually has some sense to it.
WHOLEHEARTEDLY agree. I couldn't believe the EF 4.1 update name. It's absurd. Of course it should have been 4.1.1 or 4.2. If there is no consistency in the symantic naming of frameworks the versioning actually loses its meaning.
PLEASE convey our thoughts to the PTB. Future naming/skus should be consistent, simple, and numbered in a way that the rest of the world uses so we can all keep our sanity.
Thanks, Scott!
PLEASE convey our thoughts to the PTB. Future naming/skus should be consistent, simple, and numbered in a way that the rest of the world uses so we can all keep our sanity.
Thanks, Scott!
Yes! Give me semantic versioning now!
Great initiative Scott, thanks.
Great initiative Scott, thanks.
I completely agree - How many new developers immediately understand the fact that the .net version has no correlation to the clr version? The clr versions have very clear and understandable versioning while .net versions are just assigned with no thought. Since .net 3.0, 3.5 & 3.5 sp1 all use the same clr as .net 2.0, their numbering should indicate that. Is the left hand talking to the right hand at all?
I wholeheartedly support the use of semantic versioning for the .NET Framework. I'd go further than that and suggest it's time that the Framework itself becomes modularised further so that work on different parts can proceed at the optimal speed for each module of the framework (so the faster evolving modules aren't held back the the release schedule of the slower evolving modules). Obviously each module should be individually versioned using semantic versioning.
I turned my comments into a blog post since I was getting a little long winded, but in short: +1 for semantic versioning or at the very least some common sense.
+1 for Semantic Versioning
Good luck pounding some sense in those knuckleheads doing version naming/numbering...
Good luck pounding some sense in those knuckleheads doing version naming/numbering...
I really didn't have time to read your whole post, let alone all of the many comments, which would I am sure would be very illuminating, but if I scanned your post correctly, I think I generally agree with you. I have never been particularly enthralled with any of the versioning euphemisms (branding names then SP, then R, then some other things, now Update). I suppose these euphemisms also come from marketing and are intended to give warm fuzzies to less technical folks, and generally, I suppose that is fine. Selling software to as many people as possible is the point of the business, after all.
As far as I am concerned, however, there should be a prominent display of a semantic versioning in a consistent location somewhere on the main information pages that makes it quick to determine whether an the advertised product or update with its marketing-based euphemistic version naming is more recent than that which we know is installed on our systems, as I think there are plenty of people out there who want to get there jobs done, and would rather get our warm fuzzies from our spouses, families and pets rather than from (insert software company)'s marketing department.
Sales and marketing can have as much space as they desire to sell to the business people, as long as the people who have to make it all work have a 12 or 16 or 18 point semantic version someplace consistent to know whether what is being advertised is preaching to the choir or worth learning more about.
As far as I am concerned, however, there should be a prominent display of a semantic versioning in a consistent location somewhere on the main information pages that makes it quick to determine whether an the advertised product or update with its marketing-based euphemistic version naming is more recent than that which we know is installed on our systems, as I think there are plenty of people out there who want to get there jobs done, and would rather get our warm fuzzies from our spouses, families and pets rather than from (insert software company)'s marketing department.
Sales and marketing can have as much space as they desire to sell to the business people, as long as the people who have to make it all work have a 12 or 16 or 18 point semantic version someplace consistent to know whether what is being advertised is preaching to the choir or worth learning more about.
You should have an edit post capability here Scott. After editing my post more than once, I see there are two things in there that I still would rather were not associated with my name (one simple spelling boo-boo, one grammatic wording error...) ;)
What I want to know from you, is DO YOU CARE.
Yes, I care. Even though it's not terribly important in my day-to-day work and my understanding of the versions make me sound very smart.
The semantic versioning specification looks good, and according to that spec EF 4.1 Update 1 should have been called EF 4.1.1 and not EF 4.1.5
I'm looking forward to .NET v5.0
Yes, as with everyone else I would like to see *sane* versioning from Microsoft. Why the aversion to point releases other than .5?
I would like to know where this culture of strange versioning comes from? How it came about? It seems every other software company/organisation in the world can get this right, why not Microsoft?
I would like to know where this culture of strange versioning comes from? How it came about? It seems every other software company/organisation in the world can get this right, why not Microsoft?
I consider semantic versioning a nice to have. It's a great standardized spec. Yet I can't think of a case where it would be a deal breaker.
The real question is why marketing prefers worded versioning. Confusing versioning must help marketing. If a customer is confused maybe they're more likely to agree with the bias of a marketer. Has any research been done by marketing to handle a customer that is a programmer?
The real question is why marketing prefers worded versioning. Confusing versioning must help marketing. If a customer is confused maybe they're more likely to agree with the bias of a marketer. Has any research been done by marketing to handle a customer that is a programmer?
I can deal with the version/naming nightmares - but trying to explain to someone what they need, or heaven forbid WHY they need it is where the real pain comes in for me. We can be some of Microsoft's biggest advocates, but when the pain of explaining things like this (don't get me started on licensing) - it almost easier to just recommend an alternative.
Daniel Sorensen said, "Other than Autodesk, I get the impression that software companies are afraid to go over version number 10."
The company I work for had one go to11 14. Then they switched to a the MS model of Year + Release number. I am a release engineer for that and it causes me no end of headaches.
The company I work for had one go to
There is not enough space in a single blog comment to adequately cover how inane and insane MS versioning has been/continues to be/will be.
Obviously, there's also a giant product naming problem. But version numbers definitely aggravate the whole issue.
Obviously, there's also a giant product naming problem. But version numbers definitely aggravate the whole issue.
Yes, please. Semantic versioning is so needed with technology products. We absolutely need to know how an update/upgrade/fix effects a computer we install it on (ours or a client's).
+1. I totally agree with you. In the interest of focus, I am not bothered as much by inconsistency between different products (such as your Windows vs. Visual Studio Premium/Pro) as by the confusion in the .Net runtime and Framework between runtime version, product version, update version, etc. which you point out.
I'm already used to the current versioning. If I want to see the version differences and/or details about the new version, I usually just go over to the microsoft documentation and search the internet. But, of course I welcome new approaches for evaluation.
I have nothing to add. The sheer amount of responses makes the statement quite clear. +1 for semantic versioning.
This might have something to do with the inconsistencies.
This might have something to do with the inconsistencies.
Absolutely agree, semantic versioning should be used for all Microsoft products.
I agree.
I specially don't like "service packs"
Service implies a update that fixes things and not an update that adds new things.
When u get your car serviced do you come back with a new engine?!
I specially don't like "service packs"
Service implies a update that fixes things and not an update that adds new things.
When u get your car serviced do you come back with a new engine?!
I think we all can understand naming conventions to be a bit weird when the marketers get involved in the upgrade process. For that reason anything that goes to a consumer may require a less technical naming convention, e.g. Windows 7 Service Pack 1 (instead of Windows 7.1.0.1234).
The opposite of this argument is absolutely true when you deal with technical people. I (as a dev) want to know it's Windows 7.0.0.1111 I am dealing with and that after the upgrade I will have 7.1.0.1234. Semantic versioning is something all technical people immediately understand and interpret correctly.
No need to wow us with fancy marketing speak - just the facts please!
(Nice article, Scott!)
The opposite of this argument is absolutely true when you deal with technical people. I (as a dev) want to know it's Windows 7.0.0.1111 I am dealing with and that after the upgrade I will have 7.1.0.1234. Semantic versioning is something all technical people immediately understand and interpret correctly.
No need to wow us with fancy marketing speak - just the facts please!
(Nice article, Scott!)
You do realize it's NOT .NET 4.0? According to marketing ... it's actually .NET 4. Similarly it's Microsoft .NET Framework 4 Platform Update 1 without a .0 on the 4.
;(
;(
I absolutely agree that the current naming is garbage and semantic versioning would be a massive step in the right direction.
Even if they don't go for semantic versioning, at the very least get a consistent versioning scheme across all products so that it's easy to understand what each release means and how big the likely impact is going to be.
Even if they don't go for semantic versioning, at the very least get a consistent versioning scheme across all products so that it's easy to understand what each release means and how big the likely impact is going to be.
And, oh yeah, Me and a few other already blogged about this
http://blogs.lessthandot.com/index.php/All/?p=1263
http://devlicio.us/blogs/hadi_hariri/archive/2011/05/18/did-you-just-take-a-dump-on-standard-versioning-practices.aspx
http://blog.maartenballiauw.be/post/2011/05/18/Microsoft-NET-Framework-4-Platform-Update-1-KB2478063-Service-Pack-5-Feature-Set-31-R2-November-Edition-RTW.aspx
Just in case you need more evidence.
http://blogs.lessthandot.com/index.php/All/?p=1263
http://devlicio.us/blogs/hadi_hariri/archive/2011/05/18/did-you-just-take-a-dump-on-standard-versioning-practices.aspx
http://blog.maartenballiauw.be/post/2011/05/18/Microsoft-NET-Framework-4-Platform-Update-1-KB2478063-Service-Pack-5-Feature-Set-31-R2-November-Edition-RTW.aspx
Just in case you need more evidence.
I want as many organizations as possible to use semantic versioning
I absolutely agree.... it's just plain confusing. Semantic Versioning FTW!
totally agree scott. MS versioning is an embarrassing mess. the WinFX fiasco in particular!
I agree. Use consistent version numbers, and let them come from the developer side.
Then, if marketing wants to call it "Magical Unicorn Service Release PU Squantillion Delta", let them write it in the package and ship a CD with the label to whomever receives their software via CDs - maybe other people in marketing.
But for those of us who need to actually use the product, X.Y.Z is far more helpful.
Then, if marketing wants to call it "Magical Unicorn Service Release PU Squantillion Delta", let them write it in the package and ship a CD with the label to whomever receives their software via CDs - maybe other people in marketing.
But for those of us who need to actually use the product, X.Y.Z is far more helpful.
Affirmative .I am also surprised with he convention . Semantic version scheme that you mentioned is so simple .If anyone is unclear with the numbers than a helpful name is always good to see but I always had a thought the these names are very confusing :S.....
I do hope that they will listen you...
I do hope that they will listen you...
Hey Scott,
you are so right! Versioning is important.
And by the way: Microsoft: Try to avoid that marketing replaces nice names like Indigo or Avalon with crazy last-minute-names like WCF or WPF - nobody likes these...
Stefan
you are so right! Versioning is important.
And by the way: Microsoft: Try to avoid that marketing replaces nice names like Indigo or Avalon with crazy last-minute-names like WCF or WPF - nobody likes these...
Stefan
Thank goodness someone at MS has a brain! if i never see another Update Rollup Feature R2 CTP RC3 it will be too good.
Use a nice & short name and a 3 set version number for every product. People understand product updates where it is not a massive change but a handful of new features are added - just look at Chrome, recent Firefox, OSX.
And stop using acronymns too!CTP Alpha, Beta or Preview are all better!
Get this right now MS!
Use a nice & short name and a 3 set version number for every product. People understand product updates where it is not a massive change but a handful of new features are added - just look at Chrome, recent Firefox, OSX.
And stop using acronymns too!
Get this right now MS!
I've long since given up on trying to make any sense of Microsoft's versioning schemes. Microsoft routinely breaks the accepted best practices for major-minor versioning, and that's when they bother following the "major.minor[.build[.revision]]" scheme at all. I am convinced that the "Service Pack" and "Platform Update" conventions were conceived as some sort of twisted joke.
And then there's the issue of product naming versus product versioning. Let's not forget the year-based naming scheme that has plagued the Windows and Office product lines since "Windows 95". The only time year-based naming or versioning actually makes sense is the "YYYY.Q" scheme for products which actually *have* a quarterly or semi-annual release schedule (e.g. "2010.2", "2011.1"). For products with two or three years between new releases it's just silly. While I find Microsoft's year-based naming to be rather silly, at least it doesn't openly conflict with the actual product versioning: having a product named "Office 2010" with a version number of v14.0 isn't all that bad since "2010" doesn't look like a traditional version number. The new Windows naming scheme, however, is another matter. One would think "Windows 7" would be Windows v7.0, yet it is actually Windows v6.1. I suppose "Windows 8" will be v6.11? Ugh. (I am rolling my eyes right now.)
Don't even get me started on all the SKUs. Seriously, who felt it was necessary to have six Windows SKUs? And let's not forget the nine SKUs of Visual Studio 2008. Visual Studio 2010 has been "simplified" (if you can call it that) to a mere four SKUs. Are we supposed to be pleased that the number of developer tool variations has gone from being inexpressibly absurd and incomprehensible to merely ridiculous? Hey, I have an idea: how about having two Windows SKUs: "Windows" and "Windows Server"? Visual Studio can be reduced to a single SKU (simply "Visual Studio"), given away for free, and completely decoupled from MSDN. MSDN should have only one subscription level (still paid) with volume options for ISVs to cover all their developers. There, see how easy that was?
OK, that's the end of my rant. If you're willing to try to fix any of this--even if it's just .NET versioning--then I salute you and stand behind you all the way. Good luck (you'll need it).
And then there's the issue of product naming versus product versioning. Let's not forget the year-based naming scheme that has plagued the Windows and Office product lines since "Windows 95". The only time year-based naming or versioning actually makes sense is the "YYYY.Q" scheme for products which actually *have* a quarterly or semi-annual release schedule (e.g. "2010.2", "2011.1"). For products with two or three years between new releases it's just silly. While I find Microsoft's year-based naming to be rather silly, at least it doesn't openly conflict with the actual product versioning: having a product named "Office 2010" with a version number of v14.0 isn't all that bad since "2010" doesn't look like a traditional version number. The new Windows naming scheme, however, is another matter. One would think "Windows 7" would be Windows v7.0, yet it is actually Windows v6.1. I suppose "Windows 8" will be v6.11? Ugh. (I am rolling my eyes right now.)
Don't even get me started on all the SKUs. Seriously, who felt it was necessary to have six Windows SKUs? And let's not forget the nine SKUs of Visual Studio 2008. Visual Studio 2010 has been "simplified" (if you can call it that) to a mere four SKUs. Are we supposed to be pleased that the number of developer tool variations has gone from being inexpressibly absurd and incomprehensible to merely ridiculous? Hey, I have an idea: how about having two Windows SKUs: "Windows" and "Windows Server"? Visual Studio can be reduced to a single SKU (simply "Visual Studio"), given away for free, and completely decoupled from MSDN. MSDN should have only one subscription level (still paid) with volume options for ISVs to cover all their developers. There, see how easy that was?
OK, that's the end of my rant. If you're willing to try to fix any of this--even if it's just .NET versioning--then I salute you and stand behind you all the way. Good luck (you'll need it).
Oh for pete's sake - use consistant version numbering. We use 4 numbers seperated by periods:
<major>.<minor>.<maintenance-release>.<service-pack>
Or in microsoft's case you might have something like:
<major>.<minor>.<service-pack>.<hotfix>
marketing names are ok ... in marketing and sales.
Otherwise for us techies use the version numbers.
<major>.<minor>.<maintenance-release>.<service-pack>
Or in microsoft's case you might have something like:
<major>.<minor>.<service-pack>.<hotfix>
marketing names are ok ... in marketing and sales.
Otherwise for us techies use the version numbers.
I'd have to agree with this poster. Microsoft seems to constantly try to innovate the way they display versioning to the world however the only ones that care are the ones that need to filter through the changes such as us technical people.
I say cut the product advertisements of the new latest and greatest and just tell me in the versioning whether I need to worry about small bug fixes, or major enhancements.
I say cut the product advertisements of the new latest and greatest and just tell me in the versioning whether I need to worry about small bug fixes, or major enhancements.
it's just another thing to contend with. There's no reward system for getting it right internally that I can see, and there's no community involvement where the community see that they got a result on something. Like when is it worth saying something to MS about something like this? When has it been worth saying something in the past? I
I heard in one podcast that MS have a naming department somewhere. How about adding versioning + community accountability to that?
The perception is that once MS do a code drop, everything is baked in. You can't hit the backspace key on anything.
Wouldn't it be good if the frameworks could have a refresh based on community feedback? Probably there's quite a bit of value that never gets used. Unfortunately, [Obsolete()] is the only backspace key presently.
I heard in one podcast that MS have a naming department somewhere. How about adding versioning + community accountability to that?
The perception is that once MS do a code drop, everything is baked in. You can't hit the backspace key on anything.
Wouldn't it be good if the frameworks could have a refresh based on community feedback? Probably there's quite a bit of value that never gets used. Unfortunately, [Obsolete()] is the only backspace key presently.
Microsoft's product naming in general is terrible. If the argument were that "words are easier to understand", than how can one justify creating ridiculously long names and then giving them acronyms to make them short enough?
Here's the worst one I have ever seen: System Center Virtual Machine Manager 2008 R2 SP1 Self Service Portal 2.0. Has WTF written all over it, if you ask me.
Anyone making a product, no matter what the audience, should spend a little extra time thinking about what a name should mean. A product name should be short and representative, that's all. The longer it is, the less representative it will be.
Here's the worst one I have ever seen: System Center Virtual Machine Manager 2008 R2 SP1 Self Service Portal 2.0. Has WTF written all over it, if you ask me.
Anyone making a product, no matter what the audience, should spend a little extra time thinking about what a name should mean. A product name should be short and representative, that's all. The longer it is, the less representative it will be.
Yes, this is a huge problem. When I visit a MS site to download something, odds are I won't be able to make any sense of what "version" i'm downloading. Definitely favor logical version numbers over "service packs", "rtms", "ctps", "updates", etc. And be consistent about it. It doesn't seem like it would be that difficult to use sane version numbers (example: jQuery).
Semantic versioning would be easier to understand. It doesn't matter quite as much for the software I care about most because I follow it close enough that I know what they mean no matter how they chose to label it. It's the software I don't use as often where the problem arises. A static place to go to find information about each release would be extremely helpful as well. I don't know if it is true or not, but my personal perception is that information about each of Microsoft's is spread out over any given number of websites. It's difficult to know where to go to find information about software no matter how it's labeled. You can have all the sweet ass semantic versioning in the world but if you can't map it to actual information on a site other than Wikipedia it isn't a lot of help anyway.
One question I have is this - what if your application consists of a number of components, each of which belong to you, but some of which are used on other applications? Let's say Silverlight UI A talks to Web Service B, which communicates with business/data layer C. C is definitely used in many other apps, B may be used in other apps, and A is a specific end-product.
Do you make different version numbers for each component? Also, what is the A SIlverlight component is a mixture of shared base classes and then client-specific derived and dependent classes, call this A' Now what do you version?
These various parts of the also live in different repositories.
I would love some feedback on this, though StackOverflow may be the best place for this discussion.
Cheers,
Daniel Williams
Do you make different version numbers for each component? Also, what is the A SIlverlight component is a mixture of shared base classes and then client-specific derived and dependent classes, call this A' Now what do you version?
These various parts of the also live in different repositories.
I would love some feedback on this, though StackOverflow may be the best place for this discussion.
Cheers,
Daniel Williams
Dot Net 3.5 SP1 was the biggest nightmare in recent history. The fact that a service pack severely altered the functionality, and added huge new features (Like Entity Framework) really dissappointed me. I have probably spent 100+ hours explaining why people with 3.5 do not always have EF. They need a service pack, that you can't tell if you have by the .Net version of the assemblies on your machine. Grrr.
+1 to semantic versioning
+1 if you have multiple components in your system they should all be versioned. Sql Server 2008 10.0 was fine when it shipped. But every assembly that shipping as a SP, CU, HF, QFE, etc all said 10.0 also. When they should have bumped. You can reset all of them to align again when you have a major new release. But then even an end user could look at the assembly and tell you if they have the right version or not.
+1 to semantic versioning
+1 if you have multiple components in your system they should all be versioned. Sql Server 2008 10.0 was fine when it shipped. But every assembly that shipping as a SP, CU, HF, QFE, etc all said 10.0 also. When they should have bumped. You can reset all of them to align again when you have a major new release. But then even an end user could look at the assembly and tell you if they have the right version or not.
*Please* continue to push this at Microsoft. Yes, I care. The current naming scheme (or lack thereof) is very confusing. It also makes discussing specific versions nigh incomprehensible. Another negative effect is that it makes it difficult to identify relevant information in online searches. I'm having a hard time describing this, but the current mish-mash makes search results less likely to return relevant information than if there was a consistent naming scheme like Semantic Versioning.
You wanna know how screwed up how Microsoft version numbers.
Check out what they did to Windows 7, which is actually Windows 6.1
and check out Windows Phone Mango, which is known commercially as Windows Phone 7.5 but it's actually 7.1 even though it's a huge release with 500 new features.
Check out what they did to Windows 7, which is actually Windows 6.1
and check out Windows Phone Mango, which is known commercially as Windows Phone 7.5 but it's actually 7.1 even though it's a huge release with 500 new features.
Microsoft has certainly done damage with their convoluted product names and versioning schemes.
Even in our rapid, iterative, agile world versioning is critical. Once one takes a dependency upon a discrete chunk of code, one needs to know when that dependency is broken. It shouldn't take a chain of KB articles or Googling for blog posts to actually determine that a problem exists.
Dependencies are one part of the equation. Our fast-paced world is also exploding the amount of software available which is challenging for even a version anorak to keep in their head. Straightforward versioning helps yield clarity to a complex ecosystem.
I work with a vendor of a LOB application that has recently begun digressing into the Microsoft versioning hell. This isn't exclusively Microsoft's issue, either. Microsoft has always been a role-model for the entire software ecosystem of ISV's and websites.
Thanks for your thoughts and I look forward to the outcomes of your voice being heard at MS. Any change at Microsoft can only help provide leadership to the entire ecosystem.
Even in our rapid, iterative, agile world versioning is critical. Once one takes a dependency upon a discrete chunk of code, one needs to know when that dependency is broken. It shouldn't take a chain of KB articles or Googling for blog posts to actually determine that a problem exists.
Dependencies are one part of the equation. Our fast-paced world is also exploding the amount of software available which is challenging for even a version anorak to keep in their head. Straightforward versioning helps yield clarity to a complex ecosystem.
I work with a vendor of a LOB application that has recently begun digressing into the Microsoft versioning hell. This isn't exclusively Microsoft's issue, either. Microsoft has always been a role-model for the entire software ecosystem of ISV's and websites.
Thanks for your thoughts and I look forward to the outcomes of your voice being heard at MS. Any change at Microsoft can only help provide leadership to the entire ecosystem.
Scott, firstly I'm really glad you are offering up this opportunity for the community to voice their opinion so thank you so much for that.
Where to start, oy! I could rant on a lot of product names and versions but you did a good job of showing how a few products vary in how they version.
My stance is that this is more than just a versioning problem, it is also a naming problem. Version becomes a marketing identifier as well for example "Windows Phone 7" or the the dreaded "Windows Phone 7 Series" that almost happened before they dropped the "Series". "Windows Phone 7.5" in the about actually shows up as 7.1. Let me just say this: W.T.F.
At the end of the day I want simple. If you are going to use years like "SQL Server 2008" then stick with years on that product, don't release a "SQL Server 2008 R2" which was actually released in 2010. This makes absolutely no sense to me. The argument I hear in this situation is that IT departments are more apt to upgrade if the product appears to be the same version and not another major version (which in fact it really was). Playing games with names is insulting your customer bases IT departments thinking that they don't know the difference. If IT departments in your ecosystem don't take to upgrades very well then address that issue. Naming isn't addressing the core issue. Seek the core issues and resolve them.
Same goes for betas. I assume CTP (Community Technology Preview) was created because of the stigma around "beta". Why does beta have a stigma however? The iOS community gets iOS 5 beta downloads from Apple and nobody complains. If Microsoft feels there is a negative connotation with "beta" it's because it lost the trust from it's community at some point with poor beta releases. Renaming doesn't all the sudden make things better. It complicates them.
On Twitter, the community often pokes jokes at Microsoft's verbose naming and versioning all the time. This should be an indicator things are out of control. Sometimes it feels like there is a corporate policy bonus for who can achieve the most acronyms in a single product name :P
To take the naming and versioning thing further, Microsoft commands a very big ecosystem that it has built and it's ISV's and partners look to it as an example. A result of this we see a lot of partner products with convoluted product naming and versioning. I see CTP and R2 and various other inconsistent naming/versioning out in the industry.
I really wish that products could have simple naming and simple versioning and this should be consistent as much as possible among products. I understand Microsoft is a decentralized organization however if we start to look into this even further things look very disorganized.
My wishes:
Create a group that manages naming and versioning. Show some leadership and organization.
Keep it simple.
Keep it consistent.
Make it something people can say in a discussion or sentence. Tongue twister product names don't belong.
Thanks again Scott!
Where to start, oy! I could rant on a lot of product names and versions but you did a good job of showing how a few products vary in how they version.
My stance is that this is more than just a versioning problem, it is also a naming problem. Version becomes a marketing identifier as well for example "Windows Phone 7" or the the dreaded "Windows Phone 7 Series" that almost happened before they dropped the "Series". "Windows Phone 7.5" in the about actually shows up as 7.1. Let me just say this: W.T.F.
At the end of the day I want simple. If you are going to use years like "SQL Server 2008" then stick with years on that product, don't release a "SQL Server 2008 R2" which was actually released in 2010. This makes absolutely no sense to me. The argument I hear in this situation is that IT departments are more apt to upgrade if the product appears to be the same version and not another major version (which in fact it really was). Playing games with names is insulting your customer bases IT departments thinking that they don't know the difference. If IT departments in your ecosystem don't take to upgrades very well then address that issue. Naming isn't addressing the core issue. Seek the core issues and resolve them.
Same goes for betas. I assume CTP (Community Technology Preview) was created because of the stigma around "beta". Why does beta have a stigma however? The iOS community gets iOS 5 beta downloads from Apple and nobody complains. If Microsoft feels there is a negative connotation with "beta" it's because it lost the trust from it's community at some point with poor beta releases. Renaming doesn't all the sudden make things better. It complicates them.
On Twitter, the community often pokes jokes at Microsoft's verbose naming and versioning all the time. This should be an indicator things are out of control. Sometimes it feels like there is a corporate policy bonus for who can achieve the most acronyms in a single product name :P
To take the naming and versioning thing further, Microsoft commands a very big ecosystem that it has built and it's ISV's and partners look to it as an example. A result of this we see a lot of partner products with convoluted product naming and versioning. I see CTP and R2 and various other inconsistent naming/versioning out in the industry.
I really wish that products could have simple naming and simple versioning and this should be consistent as much as possible among products. I understand Microsoft is a decentralized organization however if we start to look into this even further things look very disorganized.
My wishes:
Create a group that manages naming and versioning. Show some leadership and organization.
Keep it simple.
Keep it consistent.
Make it something people can say in a discussion or sentence. Tongue twister product names don't belong.
Thanks again Scott!
NO! NO! And NO!
They should keep the naming conventions non existant and as confusing as possible, so only interested and curious people will be able to understand and explain the differences after a few bing searches..!!
The next version should be something like .NET 4.0 super ultimate update 2 featuring binaries and xulumetrics for exponential combinatorics!!!
hehehe
They should keep the naming conventions non existant and as confusing as possible, so only interested and curious people will be able to understand and explain the differences after a few bing searches..!!
The next version should be something like .NET 4.0 super ultimate update 2 featuring binaries and xulumetrics for exponential combinatorics!!!
hehehe
Ian - Maybe we can put up a wiki and do it ourselves?
Is there already a blog and if where?
Thanks.
Really interesting post... I am also a big fan of semantic versioning and I use that in most of the projects up to now. I don't see any reason why development teams in MS shouldn't keep the semantic versioning only...
Scott,
Thanks for bringing this up and giving the community a chance to provide some feedback!
Personally, I think Microsoft's developer libraries such as .Net and DirectX should use semantic versioning. Other products like Windows, Office, Xbox, etc can use N+1, year, etc. However, everything should be versioned simply. Don't use "Windows 7 R2" or "DirectX 12.0.4.9832.12121 Magic Unicorn Edition"! Keep it simple, "Windows 8", "DirectX 12", "Sql Server 2010", "Entity Framework 4".
Thanks for bringing this up and giving the community a chance to provide some feedback!
Personally, I think Microsoft's developer libraries such as .Net and DirectX should use semantic versioning. Other products like Windows, Office, Xbox, etc can use N+1, year, etc. However, everything should be versioned simply. Don't use "Windows 7 R2" or "DirectX 12.0.4.9832.12121 Magic Unicorn Edition"! Keep it simple, "Windows 8", "DirectX 12", "Sql Server 2010", "Entity Framework 4".
Totally agreed, it's a mess.
I'd also mentioned here the strange situation with "Open-Source" projects which included into Framework. ASP.NET MVC & MEF. ). They have two lifes: one in Framework another's inside OSS-hub (codeplex).
I guess the obscure versioning of libs is from the fact that teams try to synchronize their products' versions with Framework's one. I think MS is better to split Framework on separate libraries (at lease EF, MEF, ASPMVC). I beleive it'll allow to simplify versioning of many libs.
p.s. Please no more SPs like .net 3.5sp1! Why was it not 3.6?
I'd also mentioned here the strange situation with "Open-Source" projects which included into Framework. ASP.NET MVC & MEF. ). They have two lifes: one in Framework another's inside OSS-hub (codeplex).
I guess the obscure versioning of libs is from the fact that teams try to synchronize their products' versions with Framework's one. I think MS is better to split Framework on separate libraries (at lease EF, MEF, ASPMVC). I beleive it'll allow to simplify versioning of many libs.
p.s. Please no more SPs like .net 3.5sp1! Why was it not 3.6?
I really dislike the current way versioning is going. It's so confusing.
+1 for semantic versioning.
+1 for semantic versioning.
Totally agree. This version naming is probably taken over by the marketing department which doesn't understand the mess it creates. Semantic versioning avoids that.
Agreed! Until .NET 2.0, I was rather proud for my favorite platform to remain (rather) consitent in its versionning scheme (to be compared to the Java world...). That time seems really over for now, and I usually just limit myself to remembering only major.minor versions.
I prefer semantic versioning. Its much more intelligible to have a consistent convention. The .NET versioning saga Scott references in one of the more painful ones examples of unnecessary convolution.
I also think that microsoft product names are often so generic as to make them very difficult as search terms, like .NET and SQL Server to name a few.
I also think that microsoft product names are often so generic as to make them very difficult as search terms, like .NET and SQL Server to name a few.
Scott - what else can I say other than I agree 1000%. One shouldn't need a de-obfuscation tool to understand simple versioning. Microsoft MUST get their act together and I applaude you for directing this action.
Please don't change what every developer already knows. We understand the numbering system. The first time I saw this new system, I had no idea what I need to do, or what it really means. I still don't.
Please ask them to leave the point system alone. Stay with semantic versioning all the way.
Thanks.
Please ask them to leave the point system alone. Stay with semantic versioning all the way.
Thanks.
I say either use conventional numbering or a sequence we all recognize like ".Net and the Philosopher's Stone" thru ".Net and the Deathly Hallows Part 2 3D", or .Net TOS, .Net TNG, .Net DS9, .Net Voyager, etc. OK, OK, seriously you would think that even marketing types would understand a conventional numbering scheme. That's my vote.
Developpers need a versioning scheme with the previously done remark that versions should mean something.( Major changes should only be included in major releases. Minor changes in minor releases. And so on. A service pack should only include additive changes.)
I can understand also the Sales people need good new product name to boost their sales. I think we can live with both of them. They choose the product name and follow the semantic versionning.
I can understand also the Sales people need good new product name to boost their sales. I think we can live with both of them. They choose the product name and follow the semantic versionning.
Relevant Post... and I havent read ALL the replies but here is my 5c worth. When you start getting into silverlight things get even worse because assemblies are moved between toolkits and the SDK as they move towards maturity. So, you end up needding, the .NET SDK, the Silverlight SDK, and Silverlight Toolkit , the Silverlight runtime and the Visual Studio tools and the Visual Studio Service Packs.... and they had better all be compatiable.
IMHO it has clearly been let get out of control and when the time comes and you have to do fresh installs of everything, you end up wastign huge amounts of time and getting REALLY frustrated. But then, if MS doesnt understand the benefits of versioning, maybe we are in more trouble than we thought.
IMHO it has clearly been let get out of control and when the time comes and you have to do fresh installs of everything, you end up wastign huge amounts of time and getting REALLY frustrated. But then, if MS doesnt understand the benefits of versioning, maybe we are in more trouble than we thought.
Remember crap Java versioning of the past, where JDK1.2 was called Java2 by marketing and so was 1.3, 1.4 etc.?
I can't remember the number of times I've had to go to this page to look up which version of a service pack, rollup, or update a customer has applied to exchange.
"Exchange 2010 Service Pack 1 Rollup 3-v3" but no v2. Seriously? And now there's a Rollup 4-v2... The build numbers are what you see in the UI, the build numbers are fairly semantically ordered. Why not just use those?
Also, please tell me why it is so difficult to find what the latest update is.
Are the latest updates listed on the marketing page?
Nope.
Are the latest updates listed on the technet page?
Nope.
The only viable way I've found is to search for what should be the next logical release and see if something comes up in Google. Or go to the Microsoft Download page for one of the updates and then look in the "What others are downloading" section.
[Search Google for Update Rollup 5] Oh, there's an Update Rollup 5 for Exchange 2010, that's probably the newest, right after Update 4-v2! [start downloading] Oops, that's Update Rollup 5 for Exchange 2010, not Update Rollup 5 for Exchange 2010 Service Pack 1, Google search fail! [cancel download]
Should I have searched with quotes? But what for? "Exchange 2010 Service Pack 1 Update Rollup", "Exchange 2010 SP1 Update Rollup", "Update Rollup for Exchange 2010 SP1"?
.NET versioning has definitely been in a similar shambles to the rest of Microsofts software, but it pales in comparison to it's more senior siblings.
Sigh...
"Exchange 2010 Service Pack 1 Rollup 3-v3" but no v2. Seriously? And now there's a Rollup 4-v2... The build numbers are what you see in the UI, the build numbers are fairly semantically ordered. Why not just use those?
Also, please tell me why it is so difficult to find what the latest update is.
Are the latest updates listed on the marketing page?
Nope.
Are the latest updates listed on the technet page?
Nope.
The only viable way I've found is to search for what should be the next logical release and see if something comes up in Google. Or go to the Microsoft Download page for one of the updates and then look in the "What others are downloading" section.
[Search Google for Update Rollup 5] Oh, there's an Update Rollup 5 for Exchange 2010, that's probably the newest, right after Update 4-v2! [start downloading] Oops, that's Update Rollup 5 for Exchange 2010, not Update Rollup 5 for Exchange 2010 Service Pack 1, Google search fail! [cancel download]
Should I have searched with quotes? But what for? "Exchange 2010 Service Pack 1 Update Rollup", "Exchange 2010 SP1 Update Rollup", "Update Rollup for Exchange 2010 SP1"?
.NET versioning has definitely been in a similar shambles to the rest of Microsofts software, but it pales in comparison to it's more senior siblings.
Sigh...
+1 for version numbers that make sense. On a side note, stop ruining good names like Indigo in favor of meaningless names destined for the land of TLA (e.g., WCF, WPF, et. al.)
Completely agree, the "named updates" like CTP are also easier to ignore than numbered updates - sometimes I think, "its only a CTP, ill just wait for the x.5 release"
I wholeheartedly agree. I hate the naming with the "Update", "Service Pack", etc. etc. I would rather have semantic version numbers. Also, I would like to see less different versions of products. I.e. For Visual Studio, Windows, etc. start eliminating the different versions and simplify them. Ideally it would be great if Windows just had client and server. I can see having a basic version and a pro version, but, it seems like they are breaking things down excessively and it is confusing. Everytime a new product is released, you have to analyse a complicated grid to figure out which edition you need to get for the features you need.
235 comments and not one in favour of the current mess. I have no hopes that Microsoft will learn though, we've gone through this before and they just cannot get it into their thick skulls.
I'll believe it when I see it.
I'll believe it when I see it.
The worst versioning/naming problem IMHO is with the Visual C++ redistributable packages. Not only is the naming terrible, if you don't know that a newer version exists (and with the right name), you won't find it via Google/Bing or on the Microsoft website, since no link to the newer version is found in the download page. Even more maddingly, all versions have the same filename vcredist_x86.exe/vcredist_x64.exe/vcredist_ia64.exe!
For VS 2008, for example, we have (oldest to newest):
VS 2008
VS 2008 SP1
VS 2008 SP1 ATL Security Update
VS 2008 SP1 MFC
VS 2008 SP1 MFC (yes, there is a newer version, since the first messed MFC up on non-english systems. A new version was thus released, which is called the same as the older version!!!)
For VS 2008, for example, we have (oldest to newest):
VS 2008
VS 2008 SP1
VS 2008 SP1 ATL Security Update
VS 2008 SP1 MFC
VS 2008 SP1 MFC (yes, there is a newer version, since the first messed MFC up on non-english systems. A new version was thus released, which is called the same as the older version!!!)
I like the idea of Mozilla's move towards bleeding edge, beta, and stable versions (no public numbering as such), you could use nuget to subscribe to the build quality you want then use the update mechanism to identify when updates are available and integrate them into your solution.
Clearly, a rational version number is best and semantic versioning fits the bill. Giving a run for the money with Visual Studio has to be Exchange Server. From another post today: "Earlier today the Exchange CXP team released Update Rollup 5 for Exchange Server 2010 SP1 to the Download Center."
1. Yes to semantic versioning. Scott, please make the current madness stop.
2. Totally agree with KevDog and what one things when one sees a version number.
Thanks!
2. Totally agree with KevDog and what one things when one sees a version number.
Thanks!
Last 3 days have been terrible.
I installed a fresh desktop at office with Win7 and VS2010 using my companies installers, went thru all my automated updated. Then I went home and downloaded the trial VS2010 went thru all the automated updates. Now my project that uses stuff in office does not work at home as it has libraries and updates missing.
There is no straight way to understand if I have missed a Service Pack, a Platform Update or some Cummulative Update. This is crazy. If I can only know I have 4.1.0 or 4.1.2 of a particular product things would have been very simple.
Microsoft was once the master of getting the version numbers right, last 2/3 years things have started going bad.
I installed a fresh desktop at office with Win7 and VS2010 using my companies installers, went thru all my automated updated. Then I went home and downloaded the trial VS2010 went thru all the automated updates. Now my project that uses stuff in office does not work at home as it has libraries and updates missing.
There is no straight way to understand if I have missed a Service Pack, a Platform Update or some Cummulative Update. This is crazy. If I can only know I have 4.1.0 or 4.1.2 of a particular product things would have been very simple.
Microsoft was once the master of getting the version numbers right, last 2/3 years things have started going bad.
Scott, they did it again... Windows Phone 7.5 is actually OS version 7.10.7720.68
Wha' happen?
.Net Framework 4.0.2 : http://coolthingoftheday.blogspot.com/2011/10/net-framework-402-release-information.html
.Net Framework 4.0.2 : http://coolthingoftheday.blogspot.com/2011/10/net-framework-402-release-information.html
Totally ACK to stop the versioning hell.
+1 for semantic versioning!
+1 for semantic versioning!
I think that, like user interfaces, consistency and predictability is as much a concern as originality or marketing suave. Most users have some instant understanding of 4.0.1 whereas I've never been to Chicago.
Scott, can you comment on the .NET 4.5 situation? I asked about this on Stack Overflow here:
http://stackoverflow.com/questions/8810391/will-net-4-5-introduce-a-new-version-of-the-clr
It seems the CLR is newer in .NET 4.5, but Microsoft is going to give it the exact same version: 4.0.30319. Why is that?
http://stackoverflow.com/questions/8810391/will-net-4-5-introduce-a-new-version-of-the-clr
It seems the CLR is newer in .NET 4.5, but Microsoft is going to give it the exact same version: 4.0.30319. Why is that?
New CLRs happen on Major Versions. Updates and bug fixes will happen on minor versions. For example, the CLR has been updated since .NET 2.0, but you haven't noticed it for the most part as it's been improvements and not breaking changes. In this case, it's a rev of the .NET 4 CLR.
Totally agree, I think the version numbers are moving way too fast as well. Why do they always go from .0 to .5 then the next? There are 10 possible numbers after the ., not 1.
Comments are closed.