6-week Google Chrome update cycle
A few months ago, Google Chrome switched to a new 6-week release cycle. For ordinary users, this went unnoticed due to the background automatic browser refresh mechanism. But project managers may be wondering how the transition to the new system was carried out and what difficulties they had to face.
Anthony Laforge, technical program manager of the Chrome project, made a presentation about the new cycle and, in general, as he put it , about the “comprehensive philosophy of updating Chrome”.
Anthony Laforge says that the Google Chrome release cycle is similar to developing a Web 2.0 application or website. There are no version numbers, and the process is a continuous stream. In the case of Chrome, each user himself subscribes to the update channel for his browser, depending on the level of stability, and the upgrades are automatically in the background.
That's how it was before. All developers work almost constantly in the main line of project development, and individual branches depart from some points in the main line. The branches stabilize, drawing changes from there (i.e., everything first falls into the main line).
')
In practice, for the final beta, you had to merge about 500 patches together and spend several weeks to stabilize. As a result, the final beta came out in 1-3 months, almost always getting out of the planned 13-week schedule. Developers constantly felt devastated after a job. Each time they had to work in a hurry to have time to declare their feature in this release, deadlines were violated, etc.
All this went on for a long time, and in the end Anthony Laforge decided that the situation needed to be somehow improved. Initially, it was planned to switch to a simplified 12-week cycle with 6 weeks of development and 6 weeks of beta. After drawing up the corresponding diagrams, it turned out that with three branches of development it is possible to have two parallel overlapping releases, and this will allow for the release of stable releases approximately every 6 weeks.
Of course, this approach does not solve the problem of merging patches and others, so after some brainstorming and consultations with adjacent Chrome groups: support, localization, marketing (can we move from release marketing to feature marketing?), It was decided to improve the system. In general, the new schedule forms an 11-week overlapping cycle, which so far works like a clock.
Anthony Laforge, technical program manager of the Chrome project, made a presentation about the new cycle and, in general, as he put it , about the “comprehensive philosophy of updating Chrome”.
Anthony Laforge says that the Google Chrome release cycle is similar to developing a Web 2.0 application or website. There are no version numbers, and the process is a continuous stream. In the case of Chrome, each user himself subscribes to the update channel for his browser, depending on the level of stability, and the upgrades are automatically in the background.
That's how it was before. All developers work almost constantly in the main line of project development, and individual branches depart from some points in the main line. The branches stabilize, drawing changes from there (i.e., everything first falls into the main line).
')
In practice, for the final beta, you had to merge about 500 patches together and spend several weeks to stabilize. As a result, the final beta came out in 1-3 months, almost always getting out of the planned 13-week schedule. Developers constantly felt devastated after a job. Each time they had to work in a hurry to have time to declare their feature in this release, deadlines were violated, etc.
All this went on for a long time, and in the end Anthony Laforge decided that the situation needed to be somehow improved. Initially, it was planned to switch to a simplified 12-week cycle with 6 weeks of development and 6 weeks of beta. After drawing up the corresponding diagrams, it turned out that with three branches of development it is possible to have two parallel overlapping releases, and this will allow for the release of stable releases approximately every 6 weeks.
Of course, this approach does not solve the problem of merging patches and others, so after some brainstorming and consultations with adjacent Chrome groups: support, localization, marketing (can we move from release marketing to feature marketing?), It was decided to improve the system. In general, the new schedule forms an 11-week overlapping cycle, which so far works like a clock.
Source: https://habr.com/ru/post/111637/
All Articles