Views
MeeGo Release Creation
Contents |
MeeGo Release Creation
Release timeline overview
MeeGo releases will occur every 6 months. Each release cycle will follow the same basic pattern of phases as described below. Each release will contain the MeeGo core and the existing set of MeeGo categories. From this point on wherever the terms 'Trunk' or 'Release' are used they should be taken to include both the core and the category-specific Trunks and Releases.
MeeGo releases started with version 1.0. Currently the numbers have no specific meaning other than that bigger number means newer release.
Release content specifications (features) are available in Bugzilla in bugs.meego.com, as well as in Release Trunk and Release branch in build.meego.com. Releases and builds with related release notes, images etc are published in repo.meego.com.
Road mapping and planning phase
The roadmap for MeeGo releases will appear about 18 months (3 release cycles) before the planned release date. Two months before the Trunk opens for new release content, development work starts in the MeeGo Working Groups to define and freeze the release content specification for the upcoming MeeGo release. Requirements and features are handled in Bugzilla in bugs.meego.com.
Development phase
The active development phase of a MeeGo release lasts seven months and is split into four parts:
- One month before the previous release is made, Trunk opens and the first phase of the active development starts. The first two months of the development period is intended for intrusive or big changes such as significant APIs changes, kernel version etc. Interruptions in build cycle and compatibility occur during this period. There should be no intrusive changes after this.
- The following two months are intended to be used for feature integration. MeeGo Trunk provides a stable and reliable development base during this time. The period ends with basically all the features intended for this MeeGo release integrated to Trunk.
- The two months between before branch are reserved for bug fixing and stabilization of the Release. There is still the possibility of integrating new features but this may not risk the release schedule. The period ends with the the release branched off the Trunk which then opens for the development of the next release.
- Branching phase lasts for one month during which major bugs are cleaned from the Release. Also the issues preventing first products going to market using this MeeGo release should be resolved before the MeeGo release. The intention is to get the products out from the different categories quickly after the MeeGo release. Branching month ends with the MeeGo release and only updates are provided after that.
Maintenance phase
This section describes the maintenance plan plus the updates and changes that may be made according to feedback and discussions prior to a 1.1 Release becoming available.
MeeGo aims to get products out to the market from different categories during a one-year period after a release in order for the devices always to be able to use the latest and greatest MeeGo software. During this period a lot of updates may be made in order to support the release and its users. The goal is to keep the quality stable so that updates can be put into use without problems. This is a quality-first period.
Fixes are actively integrated for two years after the MeeGo release and security fixes are integrated and updated when necessary to existing MeeGo releases.
The iterative development model - weekly cycles
Between releases in the active development cycle, work for MeeGo will run in weekly iterations, producing nightly builds and weekly releases from the Trunk. The resulting build from each iteration is used to track development progress.
Development Builds
Daily is the repository where the trunk output with the latest changes lands. This is the bleeding edge of development. This repository can be added to images but should be disabled by default.
The preview repository holds a snapshot of the Trunk and is used for the weekly preview and final image preparation. The preview repository is generated on Friday from the Trunk and is frozen until the next snapshot is taken on Tuesday for the final release. Parties working with code that depends on MeeGo but is not included in it can use the Friday preview to check the compatibility and fix critical issues for the weekly release.
Release Process
Preview images created and delivered to QA on Friday are non-official images. They serve to test major changes introduced into the Trunk and to provide a preview of the weekly image. Release Engineers have the discretion to accept, reject or queue submitted changes after the preview has been finalized. Feedback may be given to ensure the usability of the upcoming weekly releases for the users of MeeGo.
In principal, changes can still go in for the final weekly release if the changes meet the following criteria:
- The change is not a major API change
- The change is not a base system or tool-chain change
- The change addresses a showstopper found by QA in the preview release
- ...
How the code reaches the Trunk/Release
In order to integrate new code to Trunk or a release it must not break the MeeGo reference images. The reference images represent product categories, SDK and other configurations that need to be in place for MeeGo to function, development to continue and products to use MeeGo. MeeGo will provide facilities to help developers to test against the different references.
The first level of integration is called Staging, where developers work with the packages in OBS development projects. The package maintainer pushes the project towards the MeeGo Trunk/Release. MeeGo will provide an automated testing facility where test cases can be contributed. This will provide results from the different MeeGo references, since in many cases it is not feasible to obtain all the different reference devices.
When test results are of a sufficient standard the package maintainer pushes his/her code towards Trunk. These contributions are reviewed by the MeeGo Distribution/Platform maintainers and tested against the current Trunk. If they pass QA packages are promoted to the Trunk.
Making a product out of MeeGo Release
MeeGo supports a wide range of different categories of products and the release process tries to accommodate the different requirements of each product category. The Release process takes into account the following three aspects of successful product creation:
- Fast time-to-market by supporting QA in contributed reference HW for all contributions
- Fast development cycles by providing facilities to do upstream development within MeeGo and enabling easy synchronization to weekly releases via the release preview practice
- Fully open toolset for any HW or SW vendor to use for efficient SW creation
Release Versioning
Official Releases
MeeGo is released twice a year using a 6-month cycle. The release version has the following scheme
X.Y
Developer and Pre-Releases
A Pre-release is defined using the following scheme:
X.Y.[80|90].RELEASE_SEQUENCE
Where X.Y is the next release less 1, so that a 1.0 pre-release will be 0.9.80.x and a pre-release of 1.1 will be 1.0.80.x.
In general:
- X.Y – For major releases such as 1.0 and 1.1
- X.Y.80.N - alpha state
- X.Y.90.N - beta state (during freeze period)
- X.Y.0.N - updates for X.Y release
- X.Y.1.0 – Update Bundles or service packs
Examples:
- 0.9.80.N to 0.9.90.N to 1.0.0
- 1.0.80.N as the pre-release series leading to 1.1
- 1.0.90.N once we hit feature freeze on the product branch
Weekly Builds and Build Numbers
Weekly builds have the following version scheme:
X.Y-1.PRE_RELEASE. RELEASE_SEQUENCE.DATE.BUILD
This results in the following:
1.0.80.1.20100514.1
for a 1.1 pre-release.
Release counter is incremented every time a release is made, usually on a weekly basis in the development cycle but more frequently close to final release.
Repository Structure
Top Tree
The top of the tree exists of the following variants:
- Releases: For released products
- Updates: Updates on top of released products
- Builds: Weekly builds leading toward a product.