(→Project Milestone Definitions) |
(→Project Milestone Definitions) |
||
| Line 11: | Line 11: | ||
=== Project Milestone Definitions === | === Project Milestone Definitions === | ||
| - | {| class="wikitable" border="1" | + | {| class="wikitable" border="1" cellpadding="4" |
! MeeGo Project Phase | ! MeeGo Project Phase | ||
! Phase Description | ! Phase Description | ||
Contents |
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 a bigger number means a 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.
| MeeGo Project Phase | Phase Description | Phase Result Project Milestone | Validation QA Goals |
|---|---|---|---|
| Intrusive Change Phase | The MeeGo trunk opens and the first phase of active development starts. The first two months of the development period is intended for intrusive or big changes such as significant API changes, kernel version changes, etc. Interruptions in the build cycle and compatibility occur during this period. | Developer Preview (DP) | Main Data f lows verified, main performance gaps identified |
| Feature Development Phase | This phase is intended to be used for feature integration. The MeeGo Trunk provides a stable and reliable development base during this time. The period ends with all of the features intended for this MeeGo release integrated into Trunk. | Feature Complete (FC) | All Data flows verified from UX, reliability gaps identified |
| Stabilization Phase | This phase is intended for bug fixing and stabilization. The period ends with the release branched off the Trunk, which then opens for the development of the next release. | Release Candidate (RC) | All Features verified, no major performance nor reliability issues open |
| Release Candidate Phase | This phase is intended for stabilizing / critical bug fixes of the branched release. | Project Release | All features functional, reliability in place and performance targets achieved |
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.
The active development phase of a MeeGo release lasts seven months and is split into four parts:
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, for the devices to be able to always use the latest and greatest MeeGo software. During this period, a lot of updates may be made 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.