A thumbnail of the Symbian platform lifecycle.

I see that some scene setting articles will be in order to ground this blog.  Here’s my first.

What is the process by which the Symbian platform will evolve? – It will be a cycle within a cycle within a cycle.

(I’m talking in the future tense because right now we’re still getting this act together. Which also means that I might have to correct what I say here later on, but I’m pretty sure this won’t be drastically wrong.)

The Symbian platform is made up of packages, like a Linux distribution. Like a Linux distribution too, we (Symbian) own the platform, but we don’t own the packages. They are owned by upstream contributors, who could be any person or organisation. The platform will evolve by the contribution of new packages, or new releases of old ones , and occasionally the retirement of packages. We’ll be geared to deal with a daily inflow of fresh package drops.

The longest cycle is our official release cycle. We’ll make an official release of the platform every 6 months. A release will deliver a planned set of new features or improvements (and possibly removals of obselete features).  An official release will be for manufacturers to build devices on and developers to build apps on.

Inside the official release cycle comes our fortnightly release cycle. Every fortnight we’ll make a public release of the platform that represents the most stable, usable drop of the platform that we’ve achieved en route to the next official release.  A fortnightly release will be deeply tested. It will let device makers and developers take stock of how we’re getting on, allow them to keep their own developments in step with ours, and let them find bugs or gaps to feed back for fixing.

Inside the fortnightly release cycle comes our daily build and test cycle. This cycle has two threads that will run in parallel: platform build & test, and package build & test.

Every day – at least every day when any change has been comitted to the platform – we will build the whole lot, to make dead sure that we still can. We’ll also test the daily builds lightly, to make sure we can at least still boot a device or an emulator and that it’s not useless when we do. That’s the daily platform build & test thread.

The essential function of the daily platform builds will to generate every day a rev of the platform that’s stable enough to serve as the baseline build for the second thread: building and testing the daily inflow of package drops. We’ll publish the daily builds, including logs and reports so that package owners can see the latest status and get hold of the latest good baseline to build their packages against.

When a package owner sends us a drop, the critical question for us is whether it builds and tests successfully in the context of the latest good rev of the latest good daily platform build that we’ve got. So we’ll build the fresh package source together with the unchanged remainder of that baseline build. If the build is good, we’ll then go on to test it deeply. If  the package also tests successfully, then we’ll commit the fresh package source to our mainline platform repository.  That night, the whole platform will be rebuilt from that repository, with fresh source from the package drops that have been comitted that day.  All being well, we get a new good baseline to publish the next morning, and so it goes…

All not being well, we’ve got build breaks or we’ve got test failures in the platform. We’ll raise defects to the owners of the faulty packages, and our baseline will mark time until the fixes come in.

It’s the daily cycle, of course, that will set our pace. Keeping good builds rolling out steadily is what contributors need from us to keep good new code rolling safely in.