Microsoft's Windows 10 20H1 release will be first to RTM in December under Azure schedule
20H1 is Microsoft's first version of Windows 10 to be finalized under the Azure development cycle. What you need to know Windows started operating under Azure's development schedule earlier this year. This means feature updates will now be finalized in December and June. Windows 10X will RTM with 20H2 in June 2020. Microsoft's upcoming 20H1 release of Windows 10 will be the company's first version of the OS to be finalized in December, three months earlier than usual, as a result of Windows moving under Azure and adopting the "semester" based development cycle that Azure is already using. Mary-Jo Foley was first to reveal that the Windows dev cycle was being changed up earlier this year, but here's what this all means for Insiders. In the past, Windows 10 feature updates were typically finalized in March and September, but now, these OS releases are expected to be done in December and June instead. This doesn't mean Microsoft is giving feature updates less development time; this is just a result of Microsoft outright shifting the development cycle of Windows 10 updates by two to three months. Each release still gets the usual seven to nine months in development. Microsoft was able to make this change thanks to a decision it made when first moving Windows under Azure. To allow the Azure and Windows development schedules to align, it needed to skip a feature release. Windows 10's 19H2 release is the result of this, being an update that isn't a proper OS release like previous ones before it. This means Windows 10's 20H1 release is just about done. It was marked as feature-complete internally back in August, and Microsoft has been mostly focused on fixing up bugs and polishing the OS for release ever since. This is why Insiders have not seen any substantial new features in 20H1 builds for a couple of months, because the 20H1 release is done. We've got a month or so left of development before Microsoft signs-off on 20H1 in mid-December. Windows 10 20H2 This also means that work on the next Windows 10 feature update after 20H1, known as 20H2 or "Manganese" has already started development internally, and Insiders should begin receiving 20H2 builds in the next couple of weeks. On this new development cycle, 20H2 will RTM in June 2020. This is important, as this release will play a vital role in the availability of Windows 10X on new foldable PCs expected to start shipping in fall 2020. Now that 20H2 can RTM earlier in the year under the new dev schedule, Microsoft can use 20H2 as the shipping version of Windows 10X that's preloaded onto devices like the Surface Neo. This means Windows 10X will RTM in June alongside 20H2, and not with 20H1 as we had initially assumed. Microsoft needs the extra development time to make sure Windows 10X is as good as it can be at launch. Regarding desktop releases, does this mean new feature updates will be made available to the public earlier than previously? Right now, I'm not too sure. As 20H1 will be done in December, Microsoft could start shipping the update to the public as early as January, but none of my sources seem to be clear if that's actually what's happening. Microsoft may decide to keep pushing out new feature updates in the spring and fall, utilizing the Slow and Release Preview ring for extensive testing of the final build before it goes to the public. Either way, Windows is now operating under Azure's development schedule, and that means we can expect to see new feature updates finalized earlier than we've seen in the past. What are your thoughts on these changes? Let us know in the comments. Original article: Windows CentralWhy bugs in Windows updates increased
Has the number of bugs in Windows updates increased in the past couple of years? If so, what is the reason for the increase in bugs? That's the question that former Microsoft Senior SDET Jerry Berg answered. Berg worked for 15 years at Microsoft and one of his roles was to design and develop tools and processes to automate testing for the Microsoft Windows operating system. He left the company after Windows 8.1 shipped to the public. Microsoft changed testing processes significantly in the past couple of years. Berg describes how testing was done in the late 2014 early 2015 period and how Microsoft's testing processes changed since then. Back in 2014/2015, Microsoft employed an entire team that was dedicated to testing the operating system, builds, updates, drivers, and other code. The team consisted of multiple groups that would run tests and discuss bugs and issues in daily meetings. Tests were conducted manually by the team and through automated testing, and if tests were passed, would give the okay to integrate the code into Windows. The teams ran the tests on "real" hardware in a lab through automated testing. The machines had different hardware components, e.g. processors, hard drives, video and sound cards, and other components to cover a wide range of system configurations, and this meant that bugs that affected only certain hardware components or configurations were detected in the process. Microsoft laid off almost the entire Windows Test team as it moved the focus from three different systems -- Windows, Windows Mobile and Xbox -- to a single system. The company moved most of the testing to virtual machines and this meant that tests were no longer conducted on real and diverse hardware configurations for the most part. Microsoft employees could self-host Windows which would mean that their machines would also be used for testing purposes. The main idea behind that was to get feedback from Microsoft employees when they encountered issues that they encountered during work days. Berg notes that self-hosting is not as widely used anymore as it was before. The main sources of testing data, apart from the automated test systems that are in place, comes from Telemetry and Windows Insiders. Windows Insider builds are installed on millions of devices and Microsoft collects Telemetry from all of these devices. If something crashes, Microsoft gets information about it. One of the issues associated with the collecting of Telemetry is that most bugs are not caught by it. If something does not work right, Microsoft may not be able to discern the relevant bits from Telemetry data. While it is in theory possible that users report issues, many don't and at other times, issues may go under because of other feedback that Microsoft gets from Insiders. Additionally, while Insiders may report bugs, it is often the case that necessary information is not supplied to Microsoft which poses huge issues for the engineers tasked with resolving these issues. Tip: you can view the Telemetry data that Microsoft collects. Back in 2014/2015, Microsoft's Testing team would be tasked with analyzing bugs and issues, and supplying engineers with the data they required to resolve these. Nowadays, it is Telemetry that the engineers look at to figure out how to fix these issues and fixes are then pushed to customer devices running Insider Builds again to see if the issue got fixed or if it created new bugs. One of the main reasons why Microsoft stopped pushing out new feature updates to everyone at once was that issues that were not detected by the processed could potentially affect a large number of customers. To avoid total disasters like the Windows 10 version 1809 launch, gradual rollouts were introduced that would prevent feature updates from being delivered via Windows Update to the majority of machines in the early days of the release. Closing Words Microsoft exchanged the in-house Testing team with Telemetry data that it gathers from Insider Builds that it pushes to consumer and business devices, and replaced much of the PCs that it used for testing with virtual environments. https://youtu.be/S9kn8_oztsA
