Scheduled software release process: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<b><big><font color=red>For current information on OLPC software release processes, see [[Release Process Home]]</font></big></b>

{{Deprecated}}

We make changes to our software for many reasons; however, we make scheduled (major) releases in order to deliver significant changes to our downstream clients. Major releases may include interface-breaking changes. They are different from [[Unscheduled software release process|unscheduled (minor) releases]] in that they contain larger and more thoroughly planned changes.
We make changes to our software for many reasons; however, we make scheduled (major) releases in order to deliver significant changes to our downstream clients. Major releases may include interface-breaking changes. They are different from [[Unscheduled software release process|unscheduled (minor) releases]] in that they contain larger and more thoroughly planned changes.


Line 12: Line 16:
== OBJECTIVES ==
== OBJECTIVES ==


Write an Objectives page, similar to [[8.2.0]], recording:
Write an Objectives page (e.g. [[8.2.0]]) recording a consensus on:


* the target month.
* target month.
* development goals and priorities.
* development goals and priorities.
* lead customers.
* lead customers.
* feasibility of proposed changes.
* feasibility of proposed changes.

Module maintainers, product management, and the release team will be responsible for building and maintaining this consensus based on communal, customer, and institutional feedback. All three groups will be responsible for acting to achieve its mandates, e.g. as advisers, maintainers, and managers.

=== Schedule ===

We have learned that certain minimum amounts of time must be allocated to integration and testing. The following example schedule records some of this knowledge:

# >90 days before target date '''Steam'''. Changes can be proposed at will and ''should'' be proposed as early as possible.
# 60 days before target date '''Water'''. Proposals must pass muster with the release team. Release contracts should be written and integration should occur. This is ''feature-level change control''.
# 30 days before target date '''Ice'''. We branch for release and the release team produces release candidates as needed under ''package-level change-control''. Developers should be focused on fixing bugs.
# <15 days before target date '''Final Test'''. Get consensus from test, QA, and engineering communities, then finish the [[USR_Checklist|Release Process Checklist]].
# Release day. '''Announcement Day'''. Once Release checklist is complete, Kim sends announcement e-mail approving release for production.



== DEVELOPMENT ==
== DEVELOPMENT ==


Create potentially releasable changes.
Development consists of creating potentially releasable changes during a period of '''No Change Control''' and a period of '''Light Change Control'''.

=== STEAM ===
''MORE than 60 days before target date''

Prior to ''Water'' (feature-level change control), there is great freedom to propose changes because resources have not been allocated toward integrating and testing the proposed changes. We allocate these resources with [[Scheduled software release process#Contracts|release contracts]].

=== WATER ===
''60-30 days before target date''

When ''Steam'' transitions to ''Water'', changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) will require approval by module maintainers and Release Management before being accepted. Minor changes can still be added without approval for another 15 days. Changes requiring great coordination to deliver like string changes and UI changes will be deferred if possible.


== INTEGRATION ==
== INTEGRATION ==
Line 27: Line 54:
* Create release contracts for each desired change. See [http://dev.laptop.org/report/18 previous examples].
* Create release contracts for each desired change. See [http://dev.laptop.org/report/18 previous examples].
* Combine potentially releasable changes and fix any resulting bugs.
* Combine potentially releasable changes and fix any resulting bugs.

=== Medium Change Control ===


All translation packages must be final by this time. <br>
On or before this date Module maintainers propose a set of bug fixes to get into the testing branch. They usually do so by releasing a new version of their module and informing the release team about the changes it contains and the steps necessary to test those. The release team will make sure that
the relevant QA is executed and either approve the changes or ask for fixes/improvements. As soon as the changes are approved they are added to the testing build. After this date no changes are allowed in to the code without the approval of the module maintainer and the [[Unscheduled_software_release_process#Triage_Team|Release Triage team]].


=== Change Control ===

When we enter change control these items occur:
* All bug fixes or changes to code go through a triage review
* Builds for testing are labeled (RCx - release candidates).
* Limit the code churn to smaller items that can be isolated or easily tested; or if a large bug is deemed blocking for the release and the only solution is to resolve it with a good amount of code churn, then we may need to slip the release date.
* Change logs or internal release notes need to be supplied with each new release candidate.


== RELEASE ==
== RELEASE ==

Latest revision as of 18:07, 15 February 2011

For current information on OLPC software release processes, see Release Process Home

Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.

We make changes to our software for many reasons; however, we make scheduled (major) releases in order to deliver significant changes to our downstream clients. Major releases may include interface-breaking changes. They are different from unscheduled (minor) releases in that they contain larger and more thoroughly planned changes.

Process Overview

  1. OBJECTIVES: Choose a target month. Solicit goals and priorities for the release. Propose ends and means.
  2. DEVELOPMENT: Generate changes which may help to meet the new goals.
  3. INTEGRATION: Generate and execute a release contract for each desired change.
  4. RELEASE: Execute the Software ECO process to deliver the release.

Process Step Details

OBJECTIVES

Write an Objectives page (e.g. 8.2.0) recording a consensus on:

  • target month.
  • development goals and priorities.
  • lead customers.
  • feasibility of proposed changes.

Module maintainers, product management, and the release team will be responsible for building and maintaining this consensus based on communal, customer, and institutional feedback. All three groups will be responsible for acting to achieve its mandates, e.g. as advisers, maintainers, and managers.

Schedule

We have learned that certain minimum amounts of time must be allocated to integration and testing. The following example schedule records some of this knowledge:

  1. >90 days before target date Steam. Changes can be proposed at will and should be proposed as early as possible.
  2. 60 days before target date Water. Proposals must pass muster with the release team. Release contracts should be written and integration should occur. This is feature-level change control.
  3. 30 days before target date Ice. We branch for release and the release team produces release candidates as needed under package-level change-control. Developers should be focused on fixing bugs.
  4. <15 days before target date Final Test. Get consensus from test, QA, and engineering communities, then finish the Release Process Checklist.
  5. Release day. Announcement Day. Once Release checklist is complete, Kim sends announcement e-mail approving release for production.


DEVELOPMENT

Development consists of creating potentially releasable changes during a period of No Change Control and a period of Light Change Control.

STEAM

MORE than 60 days before target date

Prior to Water (feature-level change control), there is great freedom to propose changes because resources have not been allocated toward integrating and testing the proposed changes. We allocate these resources with release contracts.

WATER

60-30 days before target date

When Steam transitions to Water, changes requiring reallocation of integration, test, or downstream resources (i.e. requiring a new release contract) will require approval by module maintainers and Release Management before being accepted. Minor changes can still be added without approval for another 15 days. Changes requiring great coordination to deliver like string changes and UI changes will be deferred if possible.

INTEGRATION

  • Create release contracts for each desired change. See previous examples.
  • Combine potentially releasable changes and fix any resulting bugs.

Medium Change Control

All translation packages must be final by this time.
On or before this date Module maintainers propose a set of bug fixes to get into the testing branch. They usually do so by releasing a new version of their module and informing the release team about the changes it contains and the steps necessary to test those. The release team will make sure that the relevant QA is executed and either approve the changes or ask for fixes/improvements. As soon as the changes are approved they are added to the testing build. After this date no changes are allowed in to the code without the approval of the module maintainer and the Release Triage team.


Change Control

When we enter change control these items occur:

  • All bug fixes or changes to code go through a triage review
  • Builds for testing are labeled (RCx - release candidates).
  • Limit the code churn to smaller items that can be isolated or easily tested; or if a large bug is deemed blocking for the release and the only solution is to resolve it with a good amount of code churn, then we may need to slip the release date.
  • Change logs or internal release notes need to be supplied with each new release candidate.

RELEASE

Execute the Software ECO process to deliver the release.