Microsoft's Brave New World Needs Version Numbers
In Microsoft’s brave new world of agile, more-frequent software releases, including numerous pre-release cycles… Microsoft needs to rethink the way it communicates versioning.
Windows Management Framework (WMF) v5 has, for me, been pretty much the perfect example of what not to do, and the perfect example of Microsoft still shoehorning itself into old nomenclature that no longer fills the bill. I know a bunch of folks on the PowerShell team are probably still trying to figure out what works, too, so this isn’t meant to be a hammer-on-’em post, but WMF5’s lifecycle was, from a versioning perspective, pretty hellish.
We had several “technology preview” releases, which were simply named after their month of release. April 2015. November. Whatever. It was really difficult from within the product - e.g., via $PSVersionTable - to tell which one you were running, which made helping people difficult. None of these were supported in production until the “WMF5 Production Preview” released in late 2015, and in December we got “RTM” code. RTM means “Released to Manufacturing,” which is kind of absurd as a milestone, because there’s literally zero actual manufacturing going on. It’s just a word Microsoft is used to using. Windows 10 shipped with a production-supported version of WMF5, but it still wasn’t “final,” meaning RTM WMF is better than what shipped with the RTM OS. God willing, what ships in Windows Server 2016 will be v5.1 or something, because if we get yet another 5.0 release folks are going to start throwing up their hands and quitting.
Now that Microsoft’s all lovey-huggy with open source and Linux and stuff, can we just copy what those guys do?
Every time you release code, increment the version number. It’s that simple. There’s no “production preview,” there’s just “5.3.” And you maintain a list of what’s supported in production. If 5.3 isn’t a production milestone, fine - say so. But it’s still a real version, because it was released unto the world. The next release is 5.4. Then 5.5. And maybe 5.6 is supported in production, but once 5.7 is out, 5.6 remains supported for only 90 days. Or whatever. Just have a list of what’s supported, and increment the version number every time you release it. 5.8 might only last a week before someone finds some heinous bug and releases 5.9 - that’s fine. After that comes 5.10, and then 5.11, and so on.
6.0 is the first release of a major new evolution in the product, and it’s probably a “preview” release. 6.1 will be a bit better, with fewer bugs and more features nailed down, but it won’t be until maybe 6.5 that we get a “supported in production” release.
All of this is a lot easier to keep track of than vague “version” numbers like “April 2016 Production Preview.”
And while we’re at it, let’s have a Get-PSVersionInfo cmdlet. It can wrap around the existing $PSVersionTable variable, of course, but it can also ping a web service on Microsoft.com to tell you what the latest version is, what the latest supported version is, and whether or not your current version is supported in production. OMG, that would be _wonderful. _
`PS C:> Get-PSVersionInfo Name Value
PSVersion 5.8
ProductionOK False
LatestPSVersion 6.0
LatestProductionPSVer 5.9
`This tells me that I have 5.8, and it isn’t supported in production at this time. I can get 5.9, which is supported in production, although there’s a newer 6.0 which obviously isn’t supported in production.
So please. Vote for this on UserVoice.
Related Articles
Can We Talk About PowerShell Core 6.0?
Microsoft recently announced the General Availability (that is, a non-beta release) of PowerShell Core 6.0. A companion document detailing breaking changes, along with some of the language in the announcement, has led to more than a few inquiries in my mailbox. Most take the tone of, “have I been wasting my time learning PowerShell?!?!?” because, at first glance, PowerShell Core looks deeply less functional than its predecessor. Let me tell you what I think.
Up Next: Steve Roberts from Amazon talking about the AWS Tools
Join us this Thursday, Jan 16, 2014 at 9:30 PM EST as we talk with Steve Roberts from Amazon about the AWS Tools. Read more about it here: http://aws.amazon.com/powershell/
Verify Your PowerShell Skills
A long time ago… about a year, in fact… Jason Helmick and I started talking about a community-owned PowerShell “certification.” It went nowhere. Well, not very far.
Some background on exams: Microsoft, in my opinion, will never do a PowerShell cert. I say this having been part owner of a company that did outsourced exam development for the company. The deal is that Microsoft tries to certify _job tasks, _not _tools. _Nobody (well, maybe me) wakes up thinking, “gonna do me some PowerShell today.” No, PowerShell is the means to an end: “gonna automate me some user creation today” is more likely. And Microsoft tries to certify that end. PowerShell’s an important tool, and it already shows up on certification exams here and there.
For the most part, I agree with Microsoft’s reasoning, there. The argument can be summarized as saying “bosses don’t hire IT pros based on their ability to operate a low-level tool, they hire them to perform job tasks, which encompasses the tool.” Except that, in the case of PowerShell, I think it’d be tremendously useful for an employer to use PowerShell expertise as a discriminating factor in hiring. I mean, “someone who can automate stuff” is more valuable than “someone who can only do stuff manually,” in any situation.
So “PowerShell Verified” was intended to be a way for someone to prove - at least to themselves - that they’ve taken their PowerShell skills _to the minimum level necessary to be an effective automator. _Not a guru. Not an expert. Not Poshoholic. _Minimally effective, _who could then grow from there with experience.
So that’s what I’m going to put together.
I want to explain why I’m not using the word “Certification,” though. In my mind, certifications come from, mainly, first-parties like Microsoft. Microsoft has to jump through a lot of hoops to make sure their exam content is accurate, legally defensible, blah blah blah. They worry about security, brain dumps, and other stuff that diminishes the value of the certification. I don’t have that kind of bandwidth or their resources, so in many ways my little program will be less effective than a “real” certification. Plus, few bosses will give a rat’s patooty what that Don Jones guy said about your skillz (I can’t even convince bosses to buy you guys 12-core 64GB workstations for your desk). So my “Verified” program is going to be _low stakes, _meaning you take it to prove something to _
yourself
_.
Here’s how this is going to go.