Google Chrome release cycle

[imkingdavid]

Well, the other day I realized that Google Chrome was already on version 15.x.y.z (17 in the latest dev build at the moment), after only about 3 years of active development. Which led me to search for their release/version philosophy. Which is actually quite sensible.

While I know that there are probably very good reasons to avoid some or all of such a system for a web application like phpBB (rather than computer application), I thought it would at least be good to brainstorm some new ideas while we have the time.

First of all, here is the link to an article that explains the system and includes a powerpoint made by the Technical Program Manager at Google.

In short, here are the key points:

• New versions are released often... about one every 6 weeks, regardless of whether any given feature is ready or not
• When releases are deployed, the software automatically updates to the latest release in the background, without interrupting application use. Note: I know this may be a difficulty for phpBB since admin may need to initiate the upgrade instead of doing it automatically.
• There are 3 different channels to choose from (stable, beta, dev). Note: I recommend against providing easy end-user updates to the non-stable channels for (in my mind) obvious reasons
• Releases are meant to be a way to introduce new features to users, instead of being a goal/milestone that has to have features x, y, and z.
• As such, the software as a whole is feature driven, rather than version-number driven; the version number doesn't mean a whole lot

Here is the last paragraph of the article:

The versions start to blend together. The approach is more like updating a website than a piece of client software. The version numbers don’t really matter. What version of Amazon are you on? Exactly.

It's a good point. Websites, like Amazon, add new features when they're done, rather than waiting for a whole list of features to be completed.

One good point I saw in the power point was the following Q/A:

What would a world look like where we didn't base our marketing on releases?
We market features, no releases.

After all, people are more concerned with how the software works and what it can do than they are with what version the software is.


Benefits:

• No more people wondering "when x version will be released"
• Don't have to do such large upgrades of a lot of features all at once
• Features, improvements, and fixes are introduced into stable branch as they are ready, so more often

Potential issues:

• Does admin have to initiate upgrade or can it be done automatically?

more?

[Oleg]

The other issue that I think people tend to overlook is that as a user you are at the mercy of the developers as far as unwanted features go.

Gmail recently released their "new look". Don't like it? Tough, you don't get the option to use the old UI.

This is how most hosted services operate. They give you one product that works in one way. You cannot customize it. The company running the service on the other hand can add or delete functionality at any time.

In contrast to that, software tends to have stable functionality and stable user interfaces. Especially software that allows their users a great degree of customization I think tends to be wary of gratuitous changes that break users' settings, because those settings took a long time to be dialed in just right.

You have text editors that work the same way today as they did 20 years ago, where two random people are likely to have wildly different configurations of the same program. You also have web sites where two random people have the same exact experience but this experience changes every few months.

[brunoais]

Rapid release cycle is a hell complicated system.
We never know when a modification will break. In every single release the modification authors have to check if there were changes that will require changes to their own code. If we release that way it will be hard to make bug corrections and keep it working well.
I think we should take it easy. 1 Release 1ce in a while.
I think features should be suggested and worked in a simple way:
When version x.y is ready no new features are accepted for release locking, as soon as the locking features are done, a new sub-version is released. If this lock takes longer than 6 months all unfinished features are rescheduled to the next release. At the same time, same happens to the next sub-version. All features accepted by then are locking the release of the next version and so on and so on and son on.... (6 months of release cycle seems good to me for a project like this one).

This means: When 4.0 becomes alpha, 4.1 becomes feature freeze and 4.2 becomes the next place to suggest for acceptance. After a maximum of 6 months 4.1 alpha is released and 4.2 becomes feature freeze and 4.3 becomes the next place to suggest for acceptance (and so on)

[Elias]

Anthony LaForge, the technical program manager at Google overseeing Chrome development, created the presentation below (and posted it on Google Docs) to explain how Chrome’s development cycles work.

May i ask, what is phpBB's?

Thanks

[callumacrae]

Anthony LaForge, the technical program manager at Google overseeing Chrome development, created the presentation below (and posted it on Google Docs) to explain how Chrome’s development cycles work.

May i ask, what is phpBB's?

Thanks

Develop until there is enough for a release, and then release?

[vimishor]

Release a version often is a thing to take into consideration, but enforcing a fixed time for release cycle its a bit tricky for an open-source project. Behind Chrome is a company with a dedicated team working on it ; for phpBB is a team based on volunteering which can not be "forced" to finish something "yesterday" because tomorrow is the end of that 6 weeks release cycle.

The auto-update part sounds good, but here are few things to take into consideration. Like "how to deal with updates that will fail to deploy ?", "how to speed up updates across multiple boards ? (for hosting company's for example)", "after the update finishes, how to make sure that the current state of the FS is as it should ?"

My two cents on this:

1. Before the auto-update will start to deploy the new version, it will need to make a backup for the files affected by the new version that will be installed. (so it can rollback if something will go wrong). If the DB update will be based on migrations, it will be no need to backup the DB as well, because we can rollback easily.
2. If the DB update fails, it will need to rollback the database to previous state and also to rollback the FS to previous state (from the backup create at #1).
3. After the update is deployed, it will checked the checksum for each updated file so we can make sure that everything has been done correctly.

Taking this into consideration, each update will need to have a list of the files that will be affected and the checksum for each file.

Another solution for FS will be to fetch the changes via git, but I do not know how reliable is this, just because git is not present by default on each system. Maybe this will be a good solutions for a hosting company to update multiple installations from multiple clients and for those with VPS or dedicated server. On a shared environment I think this will not be a very reliable solution.

Any thoughts ?

[/a3]

<snip>

When releases are deployed, the software automatically updates to the latest release in the background, without interrupting application use. Note: I know this may be a difficulty for phpBB since admin may need to initiate the upgrade instead of doing it automatically.

-1 to auto-updates. That would confuse admins and possibly break things (even with safeguards in place).

Regarding the release cycle, as an outsider I am optimistic that the time between 3.1 and 3.2 will be smaller than 3.0 and 3.1, since 3.2 is already being planned. A smaller cycle between significant development releases (than 3.0 to 3.1) would be nice. I can't see a 6-week cycle working for a bulletin board though. Remember subsilver2? I'm sure many board owners are still getting used to proSilver.

[callumacrae]

<snip>

When releases are deployed, the software automatically updates to the latest release in the background, without interrupting application use. Note: I know this may be a difficulty for phpBB since admin may need to initiate the upgrade instead of doing it automatically.

-1 to auto-updates. That would confuse admins and possibly break things (even with safeguards in place).

How would it confuse admins? How would it break any more things than manual updates?

[DarkBeing]

If think maybe because some site owners tend to wait with the upgrade to the latest release till they are sure their customizations work with the latest version. If something suddenly does not work, it would be hard to tell why it does not work anymore. Was it an update or maybe something on the server site, etc. Also I could imagine it would confuse admins if a certain addon will work with their forum if they have no idea which version their board is. As well as for mod authors to tell for which versions the mods/plugins will work. But maybe that will not be an issue?

[Oleg]

Auto updates exist because users are assumed to be incompetent. Users are assumed to not understand why new versions of software are released and not care to update even if and when they do understand.

As updates typically change behavior, competent users don't want their software to change when the software feels like it, as opposed to when the user is ready for it.

It is an interesting thought exercise applying this logic to board administrators.

On an entirely separate note, automatic updates are pushed by companies producing perpetually security-vulnerable software. No company cares that a user is shooting themselves in the foot by using an old version of their software. Companies care about bad publicity generated when someone's data is stolen as a result of a vulnerability in that company's product. Software that does not have vulnerabilities discovered in it every month does not need automatic updates so much.