ProjectPolicies

Ubuntu Software Center Project Policies

Release Schedule

The Ubuntu Software Center follows Ubuntu's release schedule.

Versioning

Our versioning scheme is as follows:

The Major version number signifies the official release of a new version of Software Center. This number is bumped at or near the very last release of a given Ubuntu release cycle (e.g. 5.0.0 for Oneiric). The Minor version number is bumped for the very first release at the start of a new cycle and this signifies that development has begun for the cycle (e.g. 5.1.0 for Precise). The DevelopmentRevision is bumped at each development release made during the development cycle, as well as for each SRU for previous releases (e.g. 5.0.2 for the most recent SRU in Oneiric).

Finally, the PostBetaBugfixVersion is used rarely, and only at the very end of the cycle, usually being added at the first release after beta freeze. This indicates that only high priority and/or low-risk changes are included in the release.

Daily Build PPAs

We maintain a daily build PPA from trunk for testing.

A best effort will be made to also keep backported stable releases in the daily build PPA. If a new stable release requires updated base Ubuntu libraries, it will not be backported.

Trunk Stability

  • Trunk should always remain buildable.
  • Trunk should always pass the test suite.
  • Any tagged release in trunk should correspond to a released tarball and be especially stable and coherent.

Code Reviews

All non-trivial branches need a code review.

Examples of trivial branches:

  • translation updates and fixes
  • minor unit test updates (fixes for existing tests)
  • documentation fixes
  • version bumps
  • build system changes
  • pyflakes fixes

Examples of non-trivial branches:

  • normal bug fixes
  • new features (and accompanying unit tests)
  • refactors

Review Flow

  1. A branch will be flagged as ready-for-review in Launchpad for merging into trunk by developer A.

  2. A separate member of software-store-developers, developer B, will review the branch.

  3. Once approved, developer A will merge into trunk if able. Else developer B will.

Feature Approval

All branches that introduce features or important UI changes additionally need approval from a member of ~software-center-feature-approvers. This sign-off may implicitly come from either developer A or B above or explicitly from a third party C during the code review.

Resources and Further Information

SoftwareCenter/ProjectPolicies (last edited 2011-11-09 18:01:44 by pool-98-110-180-246)