Views
Release Engineering/Release Timeline
From MeeGo wiki
< Release Engineering(Difference between revisions)
| (16 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
== Release timeline overview == | == 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 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. | MeeGo releases started with version 1.0. Currently the numbers have no specific meaning, other than that a bigger number means a newer release. | ||
| Line 9: | Line 7: | ||
Release content specifications (features) are available in Bugzilla in [http://bugs.meego.com bugs.meego.com], as well as in Release Trunk and Release branch in [http://build.meego.com build.meego.com]. Releases and builds with related release notes, images, etc., are published in [http://repo.meego.com repo.meego.com]. | Release content specifications (features) are available in Bugzilla in [http://bugs.meego.com bugs.meego.com], as well as in Release Trunk and Release branch in [http://build.meego.com build.meego.com]. Releases and builds with related release notes, images, etc., are published in [http://repo.meego.com repo.meego.com]. | ||
| - | + | [[File:MeeGoReleaseTimeline.JPG|800px]] | |
| + | === Milestone Definitions === | ||
| + | |||
| + | {| cellpadding="5" cellspacing="0" border="1" | ||
| + | ! Milestone !! Description !! Details | ||
| + | |- | ||
| + | ! MM0 | ||
| + | | Concept for release done | ||
| + | |[[Release_Engineering/Milestones#MM0|Details MM0]] | ||
| + | |- | ||
| + | ! MM1 | ||
| + | | All planning done and development started | ||
| + | |[[Release_Engineering/Milestones#MM1|Details MM1]] | ||
| + | |- | ||
| + | ! MM2 | ||
| + | | Intrusive (high risk and priority) changes phase complete | ||
| + | |[[Release_Engineering/Milestones#MM2|Details MM2]] | ||
| + | |- | ||
| + | ! MM2.5 | ||
| + | | Optional checkpoint for features with medium risks | ||
| + | |[[Release_Engineering/Milestones#MM2.5|Details MM2.5]] | ||
| + | |- | ||
| + | ! MM3 | ||
| + | | Feature development phase completed | ||
| + | |[[Release_Engineering/Milestones#MM3|Details MM3]] | ||
| + | |- | ||
| + | ! MM3.5 | ||
| + | | Optional checkpoint for bugfixing | ||
| + | |[[Release_Engineering/Milestones#MM3.5|Details MM3.5]] | ||
| + | |- | ||
| + | ! MM4 | ||
| + | | Stabilization phase completed | ||
| + | |[[Release_Engineering/Milestones#MM4|Details MM4]] | ||
| + | |- | ||
| + | ! MM5 | ||
| + | | Public MeeGo Release | ||
| + | |[[Release_Engineering/Milestones#MM5|Details MM5]] | ||
| + | |- | ||
| + | ! MM5.1, MM5.2,... | ||
| + | | Update releases, if needed | ||
| + | |[[Release_Engineering/Milestones#MM5.x|Details MM5.x]] | ||
| + | |- | ||
| + | ! MM6 | ||
| + | | End of active Maintenance | ||
| + | |[[Release_Engineering/Milestones#MM6|Details MM6]] | ||
| + | |- | ||
| + | ! MM7 | ||
| + | | End of lifecycle | ||
| + | |[[Release_Engineering/Milestones#MM7|Details MM7]] | ||
| + | |- | ||
| + | |} | ||
=== Road mapping and planning phase === | === Road mapping and planning phase === | ||
| Line 19: | Line 67: | ||
The active development phase of a MeeGo release lasts seven months and is split into four parts: | 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 | + | # One month before the previous release is made, the 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 API 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 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 the 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. | # 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. | + | # [[Release_Engineering/Release_Timeline/Branching_phase|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. |
| + | |||
| + | === Release phase === | ||
| + | |||
| + | In preparation for a release, there are a set of main tasks that need to be performed to ensure a smooth, efficient and timely release. Task owners include the Release Engineering team, IT, the Program Office, and the Web Admins. Responsibilities range from setting up the release repositories to updating release notes and website documentation, as well as many others. | ||
| + | |||
| + | Here is the main release task list that is followed during the full 6-month cycle, with most of the tasks due 1 month before release: [[Release_Engineering/Release_Timeline/release_task_list|Release Task List.]] | ||
=== Maintenance phase === | === Maintenance phase === | ||
| Line 29: | Line 83: | ||
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.<br> | 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.<br> | ||
Fixes are actively integrated for two years after the MeeGo release and security fixes are integrated and updated, when necessary, to existing MeeGo releases. | Fixes are actively integrated for two years after the MeeGo release and security fixes are integrated and updated, when necessary, to existing MeeGo releases. | ||
| + | |||
| + | [[Category:Release engineering]] | ||
Latest revision as of 00:02, 4 May 2011
Contents |
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 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.
Milestone Definitions
| Milestone | Description | Details |
|---|---|---|
| MM0 | Concept for release done | Details MM0 |
| MM1 | All planning done and development started | Details MM1 |
| MM2 | Intrusive (high risk and priority) changes phase complete | Details MM2 |
| MM2.5 | Optional checkpoint for features with medium risks | Details MM2.5 |
| MM3 | Feature development phase completed | Details MM3 |
| MM3.5 | Optional checkpoint for bugfixing | Details MM3.5 |
| MM4 | Stabilization phase completed | Details MM4 |
| MM5 | Public MeeGo Release | Details MM5 |
| MM5.1, MM5.2,... | Update releases, if needed | Details MM5.x |
| MM6 | End of active Maintenance | Details MM6 |
| MM7 | End of lifecycle | Details MM7 |
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, the 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 API 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 the 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.
Release phase
In preparation for a release, there are a set of main tasks that need to be performed to ensure a smooth, efficient and timely release. Task owners include the Release Engineering team, IT, the Program Office, and the Web Admins. Responsibilities range from setting up the release repositories to updating release notes and website documentation, as well as many others.
Here is the main release task list that is followed during the full 6-month cycle, with most of the tasks due 1 month before release: Release Task List.
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, 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.