The latest Windows 10 Insider build 10547 does quite a bit to enhance the foundations of the Edge browser, including previewing the Object RTC API. Last week the Microsoft Edge team also took the opportunity to answer consumer questions through its Twitter Q&A. Today, in its latest Windows post, the Edge team has taken the chance to explain how it wants Edge to evolve on the technical side.
The team explains that Edge is an “evergreen” browser, which seems to be a hip way of saying the browser gets updated in very rapid cadences. The development of the Edge browser aligns with Microsoft’s “Windows as a Service” strategy, which favors frequent iterative updates over monolithic product releases. Development of this nature renders Windows and its components such as Edge not as products to be sold, but as connected services to be relied upon.
The rapid cadence development movement represents a change in the way Microsoft handles browser versioning. The Edge browser features two different version numbers: one for the Edge browser itself (the UI and everything), another for the underlying EdgeHTML rendering engine.
This is significant because both components are to be updated independently of each other. Doing so, allows advances to occur organically, without being withheld by product release milestones such as a new the sale of a new operating system.
Future EdgeHTML versioning will be updated as MAJOR.BUILD. So with the latest preview build 10547, the EdgeHTML version is at 13.10547, indicating “version 13 on build 10547.” The MAJOR build represents a significant milestone in the component’s development.
This scheme is designed to make it easy for developers and IT professionals to track features from preview builds to release branches via the major version number, and from build to build via the build version number.
Changelogs will be made available to discern the differences between the major and build versions.
[pullquote align=”left” cite=”” link=”” color=”” class=”” size=””]However, under this new scheme, updates to Edge’s version does not reflect feature changes of the underlying rendering engine[/pullquote]
This modular versioning system is critical for web developers to understand as they have traditionally relied on “browser” (Edge, not EdgeHTML) version numbers to discern feature availability and standards support. However, under this new scheme, updates to Edge’s version does not reflect feature changes of the underlying rendering engine. Changes are now represented by EdgeHTML’s versioning. Modern browser standards websites such as CanIUse have historically only needed to rely on browser version changes to track feature changes. The Edge team is actively working on bringing such web sites up to speed on this new cadence. Furthermore, web developers following UA strings should note that under this scheme, the version number that matters is the EdgeHTML version, not the Edge version numbering.
Why would Microsoft go to such lengths to introduce this new system? Part of the reason could be to enhance the developer experience. As we’ve reported earlier, the Edge team wants developers to build their own browsers based on the underlying EdgeHTML engine.
Imagine a scenario in which users are not using the Edge browser, but Developer ABC’s XYZ browser, which has a UI tailored toward specific users’ needs. Perhaps XYZ is more touch friendly, a frequent complaint on Windows 10’s feedback app for Edge. XYZ utilizes the EdgeHTML rendering engine at its core, giving the same great performance, standards compliance, and browsing experience found on the Edge browser. By updating EdgeHTML separate from the Edge browser itself, new features and standards can be enabled for developers like ABC to exploit without having to wait for the Edge UI team to get its act together.
It makes much more sense from an engineering perspective, where the company wants to push updates out as quickly as possible.
