Microsoft does plan to update Edge with the Store, partially, eventually

A while ago, I’ve talked about Microsoft having to let Edge live a life of its own. I’ll be damned. As Paul Thurrott has written it is happening. Partially. Eventually.

Microsoft has said that they do in fact plan to update Edge through the Windows Store. However, it isn’t as good as it sounds. Only Edge will be updated through the Store, that is, the front-end everyone uses. EdgeHTML, the render engine, will not get updates this way and continues to require updates over Windows Update (or put it another way: only when a new build is released to the public).

Why? The reason is simple. EdgeHTML isn’t part of Edge, it rather is part of Windows. Universal Windows Platform Apps use EdgeHTML all the time. Practically speaking, Edge (the front-end) is just another app running on the engine that happens to be a browser UI instead of a dedicated app for one cause. Updating EdgeHTML could potentiaal lead to issues with already existing apps on already existing versions of Windows 10. For obvious reasons, Microsoft doesn’t like that idea.

However, I would dare to argue that this isn’t a problem. EdgeHTML is a solid render engine already. Version 14 (the Anniversary Update release) works great and stands equal to other engines like Gecko and Blink. There really isn’t a need for a render engine to get updates every month. Twice a year is just fine. Edge on the other hand can use some attention, and freely being able to upgrade the app through the store on a regular (or perhaps irregular) base would make it that much better.

When is this going to happen? Well, don’t expect version 1607 to suddenly get updates to Edge through the Store. The safest bet is for this to start after Redstone 2’s release, maybe already during its development for Insiders…

It’s been one awesome journey

2 years ago Microsoft announced the Windows Insider Program, 1 day later, on 1 October 2014, the first Insider build – build 9841 – rolled out to Windows 7 and 8.1 users that had joined the Insider Program. The event was not just the kick-off for the Insider Program, but also for “Changelog Windows”. As we moved over from our parent address, away from studio384, to a new home, that was shortened to “ChangeWindows” and quickly, we became the go-to resource for many to find out in detail what was new in the latest Insider builds as we provided more details than Microsoft (which isn’t that hard, considering that they don’t provide anything beyond a rather limited feature list in their blogposts) and a more complete list than any other website.

In those early days, we started with the desktop-platform only. Simply because there wasn’t much else just yet. Windows 10 for phones had yet to materialize its first build, as far as the outside world was concerned HoloLens didn’t even exist and Windows 10 on Xbox One was still a dream. Server already got a Windows 10-build, but we found that to be “out of focus”. As build 9941, the first Mobile build, came around, we launched “ChangeWindows for phones” (back in the day, Microsoft called “Windows 10 Mobile” just “Windows 10 for phones”).

Quickly, we decided to merge both the desktop and Mobile website into one single website. One massive rewrite of the website later, Xbox, Server, IoT and Holographic could also join in on the fun, bringing us to the ChangeWindows we all know and love today.

And that right there has been one amazing journey. I’m proud of what ChangeWindows has become. We’re now listing over 287 individual changelogs! This is massive. The Insider Program is easily the worlds largest beta program there is, and we’re de facto the only ones really covering it in this kind of details, details even Microsoft doesn’t share. But hey, that keeps us alive, so no need to change that.

Anyway, it has been a great 2 years. In these 2 years, we’ve seen Windows 10 version 1507, 1511 and 1607 being released to the world and in the coming year, we’re probably looking for another 2 version to add to the list (Redstone 2 and 3) and I am looking forward to all of that. I hope you are too. Also, next month, Microsoft will release the public version of Windows Server 2016 and with that, all 6 platforms will have a Windows 10-release (Server 2016 build 14393 is already in preview for testers).

A new ChangeWindows

Today, however, is another big day in the history of ChangeWindows. Not only because we exist 2 years today, but also because we’re launching ChangeWindows 3.0 a little over a year after the ChangeWindows 2.0 launch. Today’s massive update does away with the build-cards, instead, we now show a timeline of releases for all platforms together and each platform individually on our main page. These new build-rows include the full changelog for each individual release.

The milestone-pages also got a massive redesign to make it much more useful for milestones that are already “in the wild”. First off, we now list every release, not just new builds, on the milestones page, which means that all updates are now listed too. Further, the tiles are now slightly bigger and provide you with a little bit more information as well. You’ll also see that the main milestone page now shows the Version share chart, as it is no longer part of the main index.

We also have a number of content policy updates:

  • Cumulative Updates are now listed individually.
  • Screenshots will no longer be provided with updates that do not have visual notable changes.

We still have some more changes to come, so if you are a fan of you’ll be able keep going there to see what’s next coming to our website.

You might want to reconsider installing 14926 on Mobile – UPDATE

Today, after being down for a week, Microsoft has started to flight builds yet again. We got an update from build 14915 to 14926 and it contains a number of small improvements. However, out of conscious I’m going to discourage upgrading a Windows 10 Mobile device to this build because there are 2 major issues in here of which I cannot believe they got past testing or could be considered non-impacting allowing it into the Fast Ring.

First of, many people are reporting that the PIN-pad does no longer appear when swiping up your lock screen. The result is that you can no longer enter your phone, leaving you with no option but a hard reset or use the Windows Device Recovery Tool. A possible solution to avoid this issue is to remove your PIN-password before upgrading. However…

…I’m also seeing a lot of reports of people being hit by an even worse issue, including myself. So far, I’ve seen reports about Lumia 435, 640, 640 XL, 735, 830, 929, 930 and 1520 whom can no longer recognize the availability of a SIM-card. You know, that thing that makes your phone a phone. The only solution to this issue appears to be using the Windows Device Recovery Tool and go back.

These 2 issues are rather work-flow-breaking and will be affecting a number of people. According to Microsoft, both issues can be solved by performing a hard reset. However, out of own experience and other reports I can confirm that this is not always the case for the SIM-card issue. This leaves people with that issue where a hard reset does not work only with WDRT, but it isn’t a perfect one at all as the WDRT still installs Windows Phone 8.1 back on all of the mentioned devices, which means you’ll also have to upgrade again to Windows 10 Mobile afterwards. Even for Fast Ring users that are well aware about the dangers of being on the Fast Ring, getting stuck with a phone that can no longer phone is quite unacceptable. Another solution would be to stick to it and wait until the next build comes around.

Anyway, on top of this madness, there are 2 other issues I’m seeing being reported quite often. This includes phones that randomly reboot over and over again and phones that are unable to (automatically) connect to a Wi-Fi network, if they get Wi-Fi enabled at all.

UPDATE: Microsoft has added these 2 issues to their list of “Known issues” and are claiming that a hard reset solves both of them. However, I’ve got to say that out of my own experience and some others reporting the same, at least the SIM-issue isn’t always solved by doing so.

Not getting 14901 yet? Here’s a solution

Yesterday, Microsoft released build 14901 to the world. However, due to Microsofts “device targeting”, many aren’t receiving this build (yet). There is however a way to get around this and force the 14901 to install in some very easy steps.

  1. Go to your Windows Insider Settings
  2. Click “Stop Receiving Insider Builds”
  3. Under the dropdown is a link to completely stop receiving builds, click that link
  4. Windows will ask you to restart, do so
  5. Go to your Windows Insider Settings
  6. Join the Insider Program again
  7. Again, Windows will ask you to restart, do so again
  8. Go to Windows Update and check for updates

After step 8, it might take a couple minutes (expect somewhere around 10 to 30 minutes, but this may take longer) before you will see the build pop up. I’m not saying this is a solution for everyone, but it certainly is helping a lot of people.

Anyway, have fun.

ChangeWindows 2.5 maintenance 7 August

On 7 August, ChangeWindows will be down for a couple of minutes for some maintenance. We will be replacing version 2.4 with version 2.5 and although you guys might not see much difference, this update is quite extensive and massive on the back-end and management-side of things. That’s all you guys need to know, but if you want to know more, go ahead. So, what does this update include?

  • Images will all be optimized to lower their download size, especially important for mobile connections and slow internet speeds. Between version 2.4 and 2.5, the total size of all images will be 24% lower.
  • We rewrote extensive parts of the code that makes up ChangeWindows, which results in a codebase that is 26% smaller.
  • Instead of using a basic Bootstrap 3.3.5 installation (all components, including Glyphicons), we’re now using a customized Bootstrap 3.3.7 installation that only contains the stuff we need, resulting in a massive drop in CSS and JS lines, and thus, shorter loading times.
  • Our server has to calculate a lot less and needs fewer requests to fetch its data. In general, these 4 points should provide you with a much faster website.
  • For milestone pages, ChangeWindows takes a custom color scheme, these used to be hard coded and thus for each new milestone, we would have to dive into the source code to add support for new milestones (so that they have their own color scheme too) and calculate darker colors based on the primary color. This is no longer needed as the website now takes care of that itself.
  • Previously, build registration and milestone registration where 2 distinctly separate systems. For example, if the name or version of an update was announced, like “Anniversary Update” and “1607”, I had to change that for each build individually, now, this only needs to be changed for the milestone itself, and all builds will follow.
  • The Rings-page is back in the navigation, as many people asked for a dedicated page for this after it was “removed” with the switch to ChangeWindows 2.0. However, it actually never was removed, we just didn’t include the page anymore in the heading as the sidebar already did what this page did.
  • This update includes a series of preparations for both Redstone 2 and Redstone 3.
  • It should be much easier for us to add new platforms in the future, for example, if the Microsoft Band is ever going to run Windows, we’ll be able to include it much easier.
  • The Backstage (our management board) has been completely revamped to be easier to use, look sleeker and recycle most code from the front-end.
  • The “vNext”-pages now show the name of the version of Windows at the top of the page instead of just “Windows 10 vNext” (e.g. “Windows 10 Redstone 2”).
  • The sub-navigation for build overviews with the Changelog, Updates and Notes tabs on is now colored in the builds ring color instead of light grey to be more visible.
  • Changelogs have an improved design on mobile, taking less space for bullet points.
  • Our logo at the top left corner is now high-DPI.

This update is mainly designed to make future extensions of the Insider Program easier to apply to our website. New platforms can be added more easily and new milestones can now be added without diving into the source code at all. We’re ready for Redstone 2, let it begin!

The race to Redstone 1 has come to an end

Earlier today, Microsoft released build 14390 to the Fast Ring (and 14388 to the Slow Ring, for those interested). And with no known issue left in the desktop and only 2 known issues left on Mobile which both will be fixed with an app update (to Voice recorder – which is already available – and Wallet), the Anniversary Update seems ready.

There are strong suggestions that 14390 is the final build. Not only the fact that the OS itself doesn’t have any known issues, but also sources from within Microsoft that confirm that 14390 is the build that will go out to the public on August 2, of course, this always can change. Microsoft themselves don’t want to confirm that yet. Meanwhile, build 14391 has been compiled and has shown up on websites like Buildfeed, but I would like to point out that that doesn’t mean anything. There is also a build 10587 and plenty builds after 10240, because another newer build is compiled doesn’t mean the older build can’t be the final bits.

Anyway, we’ll know for sure when the next update rolls out which will likely be a 14390.xx-update or perhaps a 14391+-release. We’ll see next week what it is going to be. But in the meantime, we’ve got quiet a solid build on our hands. This might be the real deal, and in that case, it’s time to put our focus on Redstone 2.

On a side note, I do happen to know a rather ridiculous issue. On Mobile, when you are setting a limit for your data with a monthly reset date, make sure to pay attention to the date that actually gets saved: Windows will, for some reason, save the day prior to the one you’ve selected. For people that have hit their limit and are suddenly reset by Windows on the last day of their month instead of the first day of the next month, this might turn into an expensive issue.

Build strings and the Windows versioning system

With the Anniversary Update’s final build coming up really soon, many people are out to guess what the “RTM” build will be. I’m using “-signs since the term “RTM” has been dropped for Windows 10 (or at least: they reather not use it in public anymore), so it doesn’t actually apply here. However, many people seem to get the whole idea wrong and are still stuck to the old rules of builds from the days of Windows Vista, even self-claimed “experts” are getting it horribly wrong:

Because not only is “10.1” as kernel version just plain bullshit, the build being 14400 is to. And guess what; so is the delta being 16384. And thus, here is my basic explanation of the Windows versioning system.

But before we can do that, what actually is Windows’ version number? There are a number of options and just for the sake of example, I’m going to take the Windows 10 November Update as a base:

  • Windows 10 November Update
  • 10.0.10586.0.th2_release.151029-1700
  • Version 1511

These three can all be used to identify last Novembers release. Generally, the Windows Insider community uses the second one to communicate about new versions since it is the only one that actually always changes for each new release. The first is just the name of the product although also often used to indicate a certain version of Windows (but since Windows is now always “10”, the long title for updates has become kind of annoying to use to identicate versions). The third option is actually new in the November Update, although retroactively used for the original Windows 10 release, too (which is now called version 1507).

I guess you can say that all are equally correct. But the name is becoming irrelevant leaving only the build string and version number. The first one is most often used by Insiders and Microsoft themselves, while the later is used by Microsoft to communicate to the general public.

The name

The name of a Windows version is rather “random”. Microsoft never followed the same pattern for more than 2 versions, except for the first 3 versions which only carried their version number as name. Ever since, we got 95, 98, Me, 2000, XP, Vista, 7, 8, 8.1 and 10.

However, due to Windows 10, even that name has become errelevant to reference to the recent versions of Windows, since they are all called Windows 10. Unless you’re willing to write down the full name of each release. This was actually Microsofts goal: make the name after “Windows” irrelevant.

The version

Since the November Update, Microsoft introduced a new versioning system that labels a version by the date it got released. In this case that was 1511, noted as YYMM where “15” stands for the year 2015 and “11” for the 11th month: November. The original version of Windows 10 got retroactively named 1507 and the coming Anniversary Update is labeled version 1607 (despite being released in August). This is straigth forward, not much explanation required.

The build string

The build string, this is the one it is all about as it is also the only one that is unique for each and every release of Windows, being a preview or final release. Despite its importance, not many people seem to clearly understand how they work, especially some “insiders” on Twitter.

So, to explain this, let’s device the string into a number of sections:


The kernel number

The first 2 numbers in a build string represent the kernel version. While they seem like a major number, their value is more fabricated. Windows Vista bumpt the version to 6.0 and ever since, Microsoft only bumped the minor number. Windows 7 carried version 6.1, Winodws 8, despite the massive change it was, carried version 6.2 and Windows 8.1 carried version 6.3. For the early development of Windows 10 version 6.4 was used and the first Windows 10 builds also launched with that number. After that, Microsft bumped it to version 10.0, it hasn’t changed ever since. WZoR is claiming that Microsoft will bump the kernel to version 10.1 somewhere between now and the compilation of the final build, which – again – is extremely unlikely.

The build number

This is the most important and most used part of the build string. The build number is unique for each and every build, each number can be used exactly once (in each lab). There can be revisions upon that build, but the same number can not be reused (although even revisions sometimes get revisions that do leave the delta and build the same and only change the date-time). This is the only artificial number that is actually bound to rules. And these rules are the following:

  • A build number can never go down
  • A build number can never be reused (exception: see above)
  • The final build must have a number devideable by 16
  • The final build must have 16384 as its delta

The last 2 rules where introduced with Windows Vista and where in place to keep some bits free for servicing releases.The 3rd rule here is the reason why the build number of a final release used to be predictable, together with the fact that Microsoft often went for a “fancy number”, and it is this rule that people like WZoR use to “predict” tbat build 14400 will be the Anniversary Update’s final release. There is only 1 minor issue with that:

The last 2 rules don’t apply anymore. With the November Update, Microsoft dropped these rules, hence why the build number could be 10586.0 for the final release. 10586 can’t be divided by 16 and 0 is – obviously – not the same number as 16384. And this claim is also bullshit:

If these rules still existed with the November Update, it would also have to follow them, but it doesn’t. The result of this rule being dropped is that Microsoft doesn’t have to jump anymore, instead, the build that is stable enough, goes out with the number it has, end of story. 10586 is already just a random number and there is no reason for the Anniversary Update to suddenly jump back to old habbits. Likely, it will be somewhere in the 1439x-series, perhaps late 1438x, but that is less likely.

Build jumps

Build jumps are artificial bumps in the build number. We’ve seen them before, and we’ll see them in the future often too. There are multiple reasons why Microsoft would suddenly skip a couple of builds:

  • During development of one version, they’ve reached a certain milestone and decide to jump to a higher build. For example, this happened after the 4th Windows Technical Preview, when Microsoft decided to jump from 9926 to 10000.
  • At the end of development, a number of builds is being reserved for updates that might require the build number to go up.
  • Shortly before the end of development, when Microsoft starts working on the next version of Windows, they skip a range of builds for escrow. An example is the gap between the Anniversary Update and the 148xx-series of builds, used for development of Redstone 2.
  • Sync the version number of Windows. An example is the jump from 11107 to 14251.
  • When they make a mistake, the build jump from build 8888 to 9200 for Windows 8 is an example for this reason. As explained earlier, Microsoft wanted to use 8888 because it is a fancy number, but after compilation, they realized it couldn’t be divided by 16.
  • And other reasons.
Fancy numbers

Microsoft used to prefer using a number that fitted with the release. Windows 95 for example carried build 950 and Windows 98 had build 1998. Since the 16-rule in Vista, using a fancy number got hareder. You could claim that Windows Vista itself does have a fancy number with build 6000, but Windows 7, 8 and 8.1 do not. Windows 7’s beta did, using build 7000. Microsoft wanted to give Windows 8 build 8888, but after compiling they realized that 8888 can’t be devided by 16. The next best thing was build 8800, but since 8888 is already past that, that number was lost to them, forcing them to something higher, eventually ending up with build 9200.

The lab name

The lab name is where a build originates from. These are often named after the feature they are inteded to develop but there are also some generic labs like “rs1_release” which are mostly used for distribution purpose and/or supposed to collect all features for the other individual branches. If you want an explanation for every (known) lab name, I suggest you go take a look here.

The date-time stamp

The final bit of a build string is rather self explaing. It is just the date and time the build got compiled on in a YYMMDD-HHMM format. For the above mentioned build string (the November Update), that would be 29 October 2015 on 17 o’clock.

Can we predict it?

That begs the question: can we predict the build number of the final release of any future version of Windows 10? The answer is: no. The only thing we can go by is that Microsoft usually goes up 1 a day, except for weekends. But even that isn’t always true as there is always a chance they might do just that, or perform a build jump. So basically, don’t let anyone fool you: it can’t be predicted accurately anymore, these times are over. Microsoft now uses the build they end up with and that’s it.

So anyone telling you that build 14400 is going to be the final Anniversary Update build is just a fool, anyone claiming that the 16-rule is still in place and simply doesn’t apply to the November Update because it is a “minor update” equally so. That’s not to say that 14400 can’t be the final number, because it can, but unless Microsoft is planning to compile for another 15 days worth of builds or does a random build jump, there is no reason to believe this will happen.

Edge vs Opera: a tale of two battery performance benchmarks

So a couple of days ago, Microsoft decided to reitterate that their browser was a great companion if you needed to get as much battery from your device as possible in a test with videos against Firefox, Chrome and Opera. Edge won that test by a serious margin.

Appaerently, that’s something Opera couldn’t stand. Probably because they recently started to claim having the best battery performance themselves with their new Battery Saver mode. How did they respond? On what I can only describe as the most childish way possible: a meme (showen below) and a rigged test.


Let’s get some things out of the way: first off, Edge is my main and favorable browser, simple because I also use Windows 10 Mobile and the integration is just amazing. So yes, I am perhaps biased towards Edge, and that’s why I’ll try to keep my opinion out of this as much as possible.

Let’s begin at the begin: Microsofts own test. What was that all about? Well, the basic setup was the following: take 4 fully charged Surface Books, open on all 4 a different browser (that being Edge, Chrome, Firefox and Opera) with their default settings and start watching a Netflix movie. Well. It’s not that simple, because to be fair, Microsofts test was also biased. But not the way you might think.

First off, while Edge, Chrome and Firefox had to run in their default setup, Microsoft decided to change 1 setting in Opera: they enabled Opera’s Battery Saver mode, rigging the test in Opera’s favor. Secondly – but this is out of Microsofts control – Netflix also causes bias. And this time, that bias is against Edge (and Internet Explorer, for that matter). While Opera, Firefox and Chrome only get 720p content from Netflix, Edge is capable of going up to 1080p, not constantly, but it can happen. And that results in Edge having to do double the work the other browser had to do. So basically, the result is that Opera is favored by Microsofts test, while Edge is actually being hold back, Firefox and Chrome are unaffected.

With all that in account, Opera is certain to win, right? Right? Well no. Opera did end second, but Edge managed to go on for a little more than an hour on top of Opera. And yes, this is quiet a specific usage case. But it is reasonable. This is something some people may actually do.


As said before, that wasn’t something Opera was to happy about. So they did their own test. A completely different test, which makes them already missing the point. But they even went a step further. But first, what did they test? I’ll let them describe it:

Step 1: Configure the system.
Charge the battery to 100%.

Step 2: Load,,,,,,, and – in separate tabs.

Step 3: In a loop, scrolling activity was simulated in one of the tabs:

For 30 seconds, pressing of Arrow Down was simulated every 100ms
5 seconds of idle time
For 30 seconds, pressing of Arrow Up was simulated every 100ms
15 seconds of idle time
Step 4: Each minute, the present battery capacity was recorded.

As you might think: step 1 is straight forward. Just do the exact same thing Microsoft did: take 3 devices, install Edge, Chrome and Opera (they didn’t test Firefox) on them by their default settings and get started. Again, nope, because just like Microsoft, Opera decided to bias this test in Opera’s favor, and it happens to be that they are Opera themselves. So unlike Microsoft, they actually made the test more favorable towards themselves, while Microsoft ended up putting Edge in the worst spot they actually could get it in with their test.

So, Opera also enabled Battery Saver for Opera? Yes, but they went one step further: they also enabled Opera’s build-in ad blocker. Something that is very relevant, especially considering the rather unrandomly selected websites they choose to perform this test. Obviously, if a browser needs to load less content, it will indeed use less power, and it just happens that Opera’s test-sites are full of advertisements. And full is quiet the understatement: in total, there are 92 ads. And I just opened these websites, I didn’t even scroll down, so if more ads are loaded by doing so, I missed out on those too. And to make it even more fun: there where a lot of heavy ads in there too, videos, expensive flash and more garbage. So that’s 92 (heavy) ads that Opera did not load. Chrome and Edge had to fight an uphill battle against Opera, a browser that didn’t have to load a major portion of the content they had to load.


Opera claimed to have beaten Microsoft with 22%. Something to which I can only say: congratulations Opera, you build a test completely rigged in your favor and now claim to be the king of the hill. Great work. The best thing off all is, Opera’s test is a situation you will never find yourselves in. Nobody has these specific tabs open in the same conditions and is pushing the up and down arrow for 30 seconds. Nobody does that. Another argument against this methodology is that this degrades your experience, some websites won’t work when an ad blocker is enabled. Edge and Chrome where just running as normal browsers.

But you know what, what Opera did here would have been just fine if they did it fair with a fair benchmark that makes sense and not for the childish reasons they did it for now. Their whole blogpost reads as if they felt personally attacked by Microsoft. They wrote it as if they had a personal vendetta with the Edge team. They even called Microsoft out on making a “huge PR effort” around this, while all Microsoft did was writing a blog, something the Edge team does more often. If anyone is making a huge PR effort here, it is Opera.

Grow up, Opera. You’ve been beaten, deal with it. But don’t worry, Microsoft has taken the crown of this ever since they went on a power consumtion reduction-rampage with Internet Explorer 9. On the other hand, according to Microsoft, Edge 14 will perform even better in this test, so I for one hope they’ll redo this test as soon as the Anniversary Update is available and kick Opera’s ass…

Slow Ring users are missing out on the more stable builds – Update 2: 14364, 14366 and 14367

A couple of weeks ago, Microsoft pushed build 14342 to the Slow Ring. I have to say that I was genuinely surprised by this. For the PC build, that is. The Slow build on Mobile worked just fine. However, I’ve had a horrible experience on build 14342 on many different devices, ranging from a Surface Pro 4, to a Acer Iconia W510, from a HP Pavilion to a Medion desktop and 4 other laptops. Horrible, every single time.

And that caught me by surprise, even on the Fast Ring. 14342 was the first build I had to roll back ever since 9879, and 9879 got a patch to solve its issues, 14342 as it stands on the Slow Ring today still has the issues I’ve suffered on all of these devices. I’m talking about power management issues (for example, my Surface Pro 4, even when completely shut down, would randomly boot, and if that happened inside its bag, get very, very hot, the result was that my battery was always at 0% after a night, even if it was at 100% the night before), performance issues, drivers that started to act up. All issues I didn’t see with 14332 nor 14352 (nor 14361, 14366 and 14367 for that matter).

And that kinda brings me to the point. Because not only these system-specific issues are gone, so are many other issues. Microsoft fixed an impressive list of problems in both 14352, 14361, 14366 and 14367 that will certainly make your live less stressful on a Windows Insider-enabled device, even bugs that are still in version 1511 are getting fixed. But don’t believe me, believe the numbers: 76 “major” bugs (as in: bugs that are noteworthy in announcements, and of course, some of these fixed bugs where introduced after 14342, but still) got fixed in these 4 builds combined, and that’s probably on top of hundreds of others that they didn’t disclose. Honestly, if I were a Slow Ring insider, for the coming builds, I would seriously consider moving to the Fast Ring. It’s unlikely things will be going downhill from here on out anyway, they are just fixing issues at this point.

To be honest with all of you though, this is horrible advice to give (morally speaking). It can always go sideways, and the Fast Ring might get a sudden very annoying bug, but right now, I feel like the Slow Ring is in fact the less stable of the 3 Insider Rings we have. The Fast Ring has come to a point where I would recommend it even for the less savey users over the Slow Ring (if the choice is Slow or Fast, otherwise, obviously stay in the Current  Branch… perhaps Preview Release Ring at best).

Would I recommend it over the Current Branch? Absolutely not. Not even for a tech-savey person. Not because the experience is bad, but just because of the fact that this is still a preview program. You might not want to deal with weekly OS upgrades, and since Windows 10 Anniversary Update is getting more stable with each and every build, I expect more and more builds to pass through to the Fast Ring and eventually the Slow Ring. These builds will keep containing known issues that are every now and then kinda annoying, perhaps by the end of this month I would. Just not now.

Anyway, this all applies to the desktop builds. For the Mobile builds, I’ve actually never had a serious problem with the Redstone 1 builds. No battery drain, no defect apps, nothing… I’ve in fact not really noticed I was using an Insider Preview at all, except for these instances where new features popped up. That’s noticeable. But in fact, here too, I would recommend the Fast Ring over the Slow Ring because these people are also missing out on some welcome fixes (60 “major” bug fixes since 14342 in 14356, 14361, 14364 and 14367). It’s your choice of course, but this is just what I would recommend.

Ho, and guys, this only applies for the rest of the Redstone 1 development cycle, don’t stay on Fast if you want a buggy-but-not-to-buggy experience afterwards, Redstone 2 builds will likely introduce some bigger bugs again.

Windows 10 Holographic now on, and much more

A couple of days ago, we launched a survey to ask you what you thought of We’ve gone through all that feedback and have been working on an updated version of our website based on that feedback. Not only that, but today, we’re welcoming the 6th Windows-platform to ChangeWindows: Windows 10 Holographic.

What’s new?

  • We’ve added Windows 10 Holographic as a new platform, including data on build 11082 and 14342 for Holographic.
  • The menu has been updated to allow faster navigation.
  • The statistics on the index have been moved to the sidebar.
  • The Ring-information is now clickable and will bring you right to the info on that ring’s build.
  • Build-cards now show a date bar with the Fast Rings, Slow Ring and Current Branch release dates for desktop and Mobile and the Preview and Release dates for Xbox, Server, Holographic and IoT.
  • Build-cards’ titles are now clickable and screenshots in build-cards now direct you to the build’s page, not the screenshot itself.
  • The Overview-page has been redesigned to use a more tile-ish design, the result is that it can show more content: while the old version showed 21 entries on my screen, the new version shows up to 42 entries! The page now shows less useless information too.
  • Fast and Slow Ring builds now have a different color, one being orange, the other being our classic yellow.
  • Some changelogs will show a secondary navigation on the top below the title information that allows you to switch between the changelog, updates released for that build and notes. For example, build 10240, 10586 and 10536 for Mobile).
  • If a build didn’t reach a certain ring, that ring is no longer displayed in the sidebar on that build’s page.
  • The build-pages have received a serious performance boost.
  • The cogs-icon in the menu lets you change the look of ChangeWindows, go try it out!

There are a couple more changes to come based on your feedback, and a couple of my own. So stay tuned for those!