Introducing Windows Insider Channels

[Corrine]

From Introducing Windows Insider Channels | Windows Experience Blog:

Later this month, the Fast ring will become the Dev Channel, the Slow ring will become the Beta Channel, and the Release Preview ring will become the Release Preview Channel. Here is what that mapping looks like:

As a result of the change to "normal" names for the various Insider rings, I'll start new threads for each ring.

 

[Digerati]

I know Microsoft is a software "development" company, but I have always felt a little alienated when they name programs for advanced users "Dev" or something similar. It takes me back to my first years as an MVP when they didn't know how to categorize me. So I was a "Shell/User" (whatever that means), or "Windows Desktop Experience". They recognized me as an expert, but clearly I was not and am not a programmer/developer. So I always felt a little out of place even though I do know my way around the Windows OS well enough to consider myself a pretty advanced "technical user".

I get Beta Channel. And Release Preview Channel makes sense to me too. When I worked for a major software development company, I used to do Alpha and Beta testing as part of my other duties besides hardware and network support. Why not call the Dev Channel the "Alpha Channel"? That makes more sense to me, especially since they have a Beta Channel. Oh well.

[Rant off]

 

[xrobwx71]

So I was a "Shell/User" (whatever that means)

See the 1980's movie, Tron... haha.

 

[britechguy]

Well, if they were to have followed the same channel naming paradigm that is used for Chromium-based Edge development they'd be:

1. Canary - true alpha, nightly builds (and I found that name clever because you are consenting to be the proverbial canary in the coal mine)

2. Dev - between alpha and beta, weekly builds

3. Beta - new builds every 6 weeks.

 

[Digerati]

I wonder if "Canary" is used to symbolize "early warning" for something disastrous - canary in a coalmine style?

 

[britechguy]

As I noted in my original comment, I think that's the obvious context, or Microsoft had some very, very stupid people (and I don't think they did) if no thought was given to that almost certain association when that Edge Channel name was initially chosen.

It's the kind way of putting "bleeding Edge."

 

[Digerati]

As I noted in my original comment, I think that's the obvious context

Gee whiz. I read that yesterday then totally forgot it when I replied today. Clearly, my GCF is flaring up again (geriatric cranial flatulence). Sorry about that.

Anyway, I bet you are right - but it seems an odd choice of words to me. Canaries were used as early warnings because the "need" for such warning was expected as inevitable. That is, in coal mines, "mine gas" (typically methane) is a very common natural occurrence. I used to work 2015 feet underground in an Arizona copper mine, so I learned a bit back in the day about mining. While such gases are extremely rare in copper mines, we still had detectors all over the place - just in case.

Anyway, while program managers for software development teams may "expect" there to be bugs, I never met a developer (and I worked with 400+ of them) who expected there to be bugs in their code. So if or when one was found, they were not happy, and genuinely embarrassed. Of course it is always better to find them "in-house" rather than by a customer out in the field, but still - it seems almost like a demonstration by management of their lack of confidence in their team to name that channel "Canary" - as though they are expecting there will be developer mistakes, instead of being ready - just in case one slips by. And yes, as a manager, you have to expect mistakes. But you don't want to tell your teams you expect them to screw up.

We had "peer reviews" too - which were brutal (no room for pride or personal feelings to get in the way there). The individual "module" development teams would review their own code amongst themselves to look for bugs and only after the code passed muster there, would the code go to more widespread "Alpha" testing.

 

[Digerati]

It's the kind way of putting "bleeding Edge."

Yes, but a bleeding edge is there intentionally - not by mistake.

 

[britechguy]

Having been in software development myself, many moons ago, on some very complex systems where different teams were working on different subsystems, and where the specifications were always in flux (whether they were supposed to be or not), I always expected bugs in alpha testing.

It's seldom, in those situations, where everyone is "singing from exactly the same sheet of music," and even when they are, "tempo markings" can be interpreted somewhat differently depending on the conductor(s) and performer(s).

Software development is an art, not a science (though there's plenty of science in it), and is and always has been an iterative process. And those iterations are often because of bugs. I don't think that there exists such as thing as bug-free software, just software where the execution paths of the masses have not yet encountered the ones still hiding.

 

[Corrine]

Based on the information published in What’s next for Windows 10 updates, instead of a new topic, I've renamed the thread from "Windows 10 Insider Builds From Development Branch" to Windows 10 Insider Dev Channel (Fast Ring) .

With the the release today, a new thread was created for the Beta Channel: Windows Insider Beta Channel Builds for 20H2 (Slow Ring).

 

[Digerati]

Having been in software development myself, many moons ago, on some very complex systems where different teams were working on different subsystems, and where the specifications were always in flux (whether they were supposed to be or not), I always expected bugs in alpha testing.

That's how it was with us. My company (originally Sterling Software, later Northrop Grumman IT) developed and maintained the software, built and maintained the workstation and server hardware, and all the associated networking equipment for a secure "compartmentalized" DoD and US State Department global messaging system. It was a very complex system and in its 25 year history that I am aware of before I retired, over 30 million highly classified messages were sent between various embassies in several countries, US and allied military headquarters, US Navy Fleet "flagships", as well as the Pentagon, State Dept, and White House. And not a single message was ever lost or went unaccounted for - ever.

Any way, to your point - what you called subsystems, we called modules. And again, the team leaders and managers expected bugs to be found in Alpha. That was the point of Alpha - to shake the bugs out. But the individual coders who wrote the code for their respective "modules" all hoped and prayed no bugs were found. So when bugs were found, it was a personal let-down for that coder. A pride thing. And IMO, nothing wrong with wanting to do your job right.

One thing we noticed was there rarely were bugs found in the individual modules. It was when they started putting modules together that the majority of problems surfaced. That's when finger pointing started and that was when I was glad I was just a hardware guy, pulled in to help with testing, pretending to be one of our end-users!

I've renamed the thread

Thanks Corrine!