I don’t know what the biggest project is that you work on, and how do they manage it? Today we take a look at how a huge project like Microsoft Edge is versioned.

Originally written by: Big Brother Guo Lin (interested in big official account)

Have you ever wondered how a huge project like Microsoft Edge is versioned?

Of course, I need to explain this first, because Edge is such a huge project that many people may not have the idea.

In fact, I had no idea, because I knew THAT I was just touching the tip of the iceberg, and that most people were probably getting a glimpse of the code in this project.

Edge is a browser developed by Microsoft based on Chromium, which is an open source browser project developed by Google.

So how big is Chromium? Unfortunately, I can’t find the latest numbers, but according to 2019, the Chromium project has over 34 million lines of code and over 25 million lines of pure code (minus comments and blank lines).

There is no doubt that this is an aircraft carrier, so no one can claim to know everything about the project.

Edge is going to be a lot bigger than Chromium, because Microsoft is going to add a lot of their own functionality on top of Chromium.

So back to the beginning, have you ever wondered how a huge project like Edge is versioned?

Today we’re going to reveal it.

First of all, the Edge versioning and publishing rules I’m going to cover were not invented by Microsoft, but follow exactly the same rules as Google Chrome (it’s based on the Chromium kernel, after all) and therefore don’t involve any internal Microsoft secrets.

I think this set of rules is pretty scientific and mature, and I’m sure there are plenty of other mature projects besides Edge and Chrome that use similar rules. For small projects that haven’t yet developed their own rules, I thought it would be a good time to take a look at the things in this article and make your version management more scientific.

Let me introduce you to the concept of Chromium kernel version number.

For example, Chrome 80 was released, Chrome 90 was released. This later version number corresponds to the Chromium kernel version number.

Many domestic browsers are also based on the Chromium kernel, and they sometimes advertise the Chromium kernel version number.

For example, QQ browser is based on Chromium 70 kernel.

360 security browser is based on Chromium 86 kernel development.

So what are the rules by which the kernel version is upgraded?

The Chromium rule is to update the kernel every 6 weeks, which is pretty much unchangeable. (Starting in September, Chromium has changed the rule to update the kernel every 4 weeks, but since it’s in the future, this article is still going to update the kernel every 6 weeks.)

That is, if the current latest Chromium kernel version is 90, then six weeks later it will be 91, and so on.

During those six weeks, hundreds of thousands of code will be committed to the Chromium mainline repository, and these code changes will become all functional differences between the Chromium 90 and 91 kernels.

With that in mind, let’s go back to Edge.

Currently, I work on the Edge Android team at Microsoft, and there is only one official channel for Edge Android: Google Play. (Although Edge can be downloaded from a number of mobile app stores in China, some of those stores may have been downloaded from other locations, and some may not have been updated very quickly.)

If you try to search for Edge on Google Play, you’ll see that there aren’t just one version of Edge, there are four.

This for some small white users may directly give the whole meng circle, do so many versions of what, I do not know which good to use.

Yeah, why don’t we just put a stable version on the shelves? Why Canary, Dev, Beta?

This is because each release has its own unique role, and the combination of the four releases makes the project extremely stable and robust.

Now I’m going to take a look at each of the four versions and what they do and why they exist.

Microsoft Edge Canary

Canary, which means Canary, is a common word in the software development industry, but not many people actually know what it means.

Early on the term was used in the field of mining. Miners bring a canary into the pit to work. Because the canary is sensitive to harmful gases, it will die before humans can detect them, so that the miners can find harmful gases and take protection as soon as possible.

In the software world, the same word for Canary, which basically allows us to detect problems in our software at an early stage.

If you choose to become a user of Edge Canary, you’ll be able to check out the latest features added to Edge for the first time. Because Canary releases one version per day.

Which means that something I wrote today, you can experience in Edge Canary tomorrow.

Of course, in addition to experiencing new features, you will also experience a lot of new bugs. Because, as I said, the Canary version is designed to detect problems very early on, so it’s pretty unstable. Please don’t be surprised if there are any missing functions or crashes. We will also fix them in time according to the problems detected by users.

However, this release frequency may not be appropriate for every project, and if it’s a small project, there may not be a lot of code change during the day, so a release per day doesn’t make a lot of sense.

Edge, on the other hand, has tons of code going into the mainline codebase every day. Edge now shares the same code base across the platform, and there are updates from PC, updates from mobile, and updates pulled from Chromium every day. So there are a lot of things that are different about the Canary version every day, and although we don’t know exactly what they are (everyone is only responsible for their own part, after all), the Canary version is always available to people who know what it is and ask questions.

That’s what the Canary version is all about.

Microsoft Edge Dev

Edge Dev and Edge Canary are actually somewhat similar. As you can tell from the name, it’s also intended to give users a taste of Edge’s latest features at an early stage of development.

But the Dev version is less aggressive than the Canary version, which releases weekly releases instead of daily.

Yes, there are only so many differences.

But while there is just a difference in the frequency of publication, the audience they are targeting is completely different.

Canary is aimed at the hobbyist type of user who is willing to update a new version every day, perhaps with a minor change, just to get the first taste of the new features that the Edge team developed the day before.

On the other hand, the Dev page is aimed at a more conservative audience, for whom daily updates are too frequent (I personally don’t like apps that update too often), and weekly updates are just right for them to experience all the new features that Edge has introduced in general this week.

In addition, the Dev version is much more stable than the Canary version. If you’re a user of Canary, and you’re fine with your browser today, and you update to a new version tomorrow, you might have a flashback.

This is much less likely because the Canary version only ships once a week, and there is a high probability that problems encountered on the Canary version will be fixed on the Dev version, so you can be relatively secure in updating the Dev version.

In summary, the Dev version is more suitable for users who want to experience new features but also want a stable version.

Microsoft Edge Beta

In terms of the frequency of updates, both Edge Beta and Edge Dev are updated at about the same rate, with Beta releases coming out once a week.

However, the roles of Beta and Dev are completely different.

In the software industry, a Beta is usually an imminent release, where the main features are stable and no major changes are expected.

Edge Beta means the same thing.

As mentioned earlier, Dev will be updated once a week. After six weeks of iteration, the Dev version will go into Beta. The Beta version then inherits the Dev kernel number, which is incremented by one.

For example, Edge is developing new features based on the Chromium 90 kernel, and after six weeks of development, the version will become Beta, so Edge will release a Chromium 90 Beta, and the codebase kernel that is being developed will become Chromium 91.

In this case, Canary and Dev users will soon be able to experience the Chromium 91 kernel version, while Beta users are just getting Chromium 90.

The release of a Beta means that all of the features in this development cycle have been completed, and its mission is to steadily deliver those features in this development cycle to users, rather than introducing additional features in the next development cycle.

After six weeks of iterative development, functionality is improved, but stability is not guaranteed, which is why the Beta is so valuable.

Similar to Dev, Beta releases will be released once a week, but these releases will not add any new features, but will only fix various bugs found by online users to improve the stability of the Beta.

Microsoft Edge

After another six-week iteration of the Beta, the bugs are mostly fixed, and the current Beta is a fairly stable version that will be converted into the official Microsoft Edge release.

If we look at the current point in time, when the week 6 Beta turned into the official release, that’s when the week 6 Dev version turned into the Beta. The Beta will then start a new six-week stability testing cycle, while Canary and Dev will start a new six-week development cycle, and so on.

So, according to this rule, if you are an Official Edge user and you currently have an Edge 90 version, the Beta version must be Edge 91, while Canary and Dev are already Edge 92.

That’s why the version management and distribution rules used by Edge (and also for Chromium) are fairly mature and scientific, ensuring that every official release is stable and that every release has an adequate life cycle.

Six weeks of feature development plus six weeks of stability testing meant that all bugs that needed to be found were found and resolved during the development and testing phases, so it was safe to go live. Compared with some of the previously popular hot repair technology in China, it can not be used overseas, and it is not necessary, because even without the use of these black technologies, we use software engineering and management can also be very good in advance to ensure the stability of a good version.

The life cycle of each official release is also important. Some of the apps I’ve found myself using don’t have any regular update rhythm at all, often giving you a new version every now and then.

I am usually a person who has to upgrade when there is an update. However, some apps upgrade today and then tell you that there is a new version two days later. The update log is to fix some bugs.

This is not the performance that an excellent App should have. They are testing the Canary version with the users of the official version. After a long time, I don’t want to upgrade this App any more, because I will let you upgrade again two days after upgrading.

The Edge mechanism ensures the lifetime of each official release. It is updated every 6 weeks, neither too often to annoy users nor too long to lose users, and each update corresponds to a new Version of the Chromium kernel.

Therefore, the functions and user groups of these four versions are understood. Canary is for hobbyists; The Dev page is aimed at users who want to experiment but also want some stability; The Beta page is for people who want to see the latest official release 6 weeks in advance, but are comfortable with bugs. The official layout is to the majority of ordinary user groups.

Now you know how a huge project like Edge does version management.

After introducing these knowledge points about Edge, let’s talk about the current situation of mobile Edge.

If you’re a careful user, you might notice that the current official Version of Edge on Google Play is still based on Chromium 77, while Chrome is already based on Chromium 91.

Based on the frequency of upgrades in the last 6 weeks, the 77 kernel is almost two years old.

Why is there such a big difference?

That’s because Edge on PC wasn’t originally developed in Chromium, using Microsoft’s own browser kernel, while Edge on mobile was Chromium. At that time, PC and mobile code was completely unrelated and everyone did their own thing.

Later, When Microsoft abandoned its browser kernel and Edge switched to Chromium on PC, the Edge department made the decision to require a unified code base across the platform.

But the platform-wide code base is not that simple, which means that mobile and PC can no longer do things separately, but at the same pace, at the same pace, and with the same kernel version.

As a result, Edge on mobile hasn’t updated the Chromium kernel since then, and has spent nearly two years working on a new all-platform converged version. It will be based on the latest Chromium kernel, and there will be a new version of Edge based on the latest Chromium kernel in real time (with a delay of up to a few days).

There’s a new, platform-wide Edge coming out later this month, and you’ll see the Edge kernel jump from Chromium 77 to Chromium 92, which is quite a revolutionary upgrade.

However, you can choose not to wait until later this month, but to try out the new Edge today. The reason is that Edge Beta needs to be iterated for 6 weeks before it becomes Edge, which means that Edge Beta is already Chromium 92 and has been in Beta for a long time.

If you’re interested, please join the Edge Beta. In addition to getting to play with the latest kernel Edge, it will help us test out more problems and release a more stable version of Edge to the general public in a few weeks.

Download for Edge Beta is:

Play.google.com/store/apps/…

Note: Your phone can access Google Play.

The author think

Most of the development in the past used the idea of centralized management, centralized management of the same resources. As the project developed, the drawbacks became obvious: more and more resources were centrally managed and more and more difficult to develop by multiple people, often affecting the whole system.

Especially in large companies or projects, the adverse effects of these disadvantages will be magnified several times, so many companies or projects now choose plug-in and component programs.

If you haven’t mastered these techniques yet, it’s time to check out these two study notes compiled by the masters.

Componentized learning manual

The data is divided into three blocks

  • Chapter 1 Understanding the componentization of Android
  • Chapter two: Componentization of Android
  • Chapter 3 Evolution of Architecture (Dachang)

The first chapter Android componentization understanding directory

  • Difference between componentization and modularization
  • The difference between componentization and plug-in
  • Advantages of componentized development
  • Business logic layer

Chapter two: Android componentization

  • Componentized demonstration case
  • WanAndroid APP componentization project with demo

Chapter 3 Evolution of Architecture (Dachang)

  • Componentized Architecture practice from Zhixing Android Project
  • Get the App
  • WeChat App
  • Mushroom street App
  • IQIYI App
  • Meituan App
  • Ctrip App
  • Pay treasure to App

The manual is open source to share, click here to get the complete version of this manual for free!

Plug-in learning manual

For details, please refer to Android- third-party open source framework – Activity plug-in principle (Tencent experts best plug-in explanation)

Here we share a plug-in advanced learning manual.

The first chapter is the history of plug-in technology

Chapter 2 Principle of plug-in

The third chapter is an exploration of Android plug-in

  • Implement a plug-in framework from scratch
  • Implement a plug-in framework from scratch

Chapter 4 Evolution of Architecture (Dachang)

  • DroidPlugin for 360 plug-in development
  • Didi VirtualApk combat
  • Plug-in for Android refactoring based on VirtualAPK
  • Neptune framework of iQiyi plug-in principle analysis
  • 360 open source comprehensive plug-in framework RePlugin
  • Tencent plug-in framework Shadow project analysis

The manual is open source to share, click here to get the complete version of this manual for free!

The last

You got a dream, go get it. Come on!