Xubuntu

Chapter 10. Release Cycle

Table of Contents

Planning
Developing
Testing
Releasing
Maintaining

This section loosely describes the stages of a development and release cycle.

Planning

Planning the release is conducted in three phases:

  • Brainstorming

  • Approving blueprints

  • Finalizing specifications

During the brainstorming phase the contributors determine what they would like to work on during the release cycle, including proposals for changes in default applications. Anybody can add items to the list. Settling on the goals in advance will make planning, focusing and estimating the likelihood for the features to be implemented easier.

After the brainstorming is over and before or on the Feature Definition Freeze day, the Xubuntu team will approve or reject the proposed blueprints. Any items with no assignee or rationale will be automatically rejected, but having them will not guarantee that the blueprint is approved. Other criteria include, but are not limited to: likelihood of getting the feature implemented, maintenance weight in the future, possible stability issues, influence on other blueprints, et cetera. The approved blueprints compose the roadmap for the release being developed.

After blueprints are approved, they should be finalized and detailed specifications should be written. These specifications should document the proposed changes and help guide the implementation.

Once the detailed specifications are ready, the developer team should coordinate with the QA team about the required scale and schedule of testing. The QA team will then build a schedule for testing for ISO and package tests. Additional requests for testing during the cycle should be sent out only after consulting the QA team.

The Ubuntu freezes define the deadlines for implementation.

Developing

In addition to implementing the features and/or improvements set in the roadmap, there are a number of tasks which will occur during each release cycle:

  • Xubuntu packages will be synced or merged with Debian as appropriate

  • Bugs reported by users will be reviewed, fixed, and/or passed upstream

  • Attempt to reduce our delta by pushing appropriate patches upstream

  • Evaluate the seeds to ensure we are shipping the optimal software

  • Work on improving and updating the Xubuntu documentation and artwork

Testing

Throughout the release cycle and even more so towards the end, we will test Xubuntu to ensure that Xubuntu is a quality product that we are proud of.

The most important goal of the testing is to find as many bugs as possible and report them with sufficient detail to the Ubuntu QA trackers. To read more about conducting tests and reporting them, refer to the QA tracker wiki page.

ISO testing

The Xubuntu team will do its best to ensure that released milestone ISOs have enough tests completed. We will also test daily builds, upgrading through supported release paths and running the development version regularly to help detect problems and make sure the changes made meet the release goals, work as expected and do not cause regressions.

The following schedule is used for daily testing:

Scheduled time Action
Beginning of cycle Send testing schedule via both the developer and users mailing lists as well as the Launchpad testing team.
Monthly As required, send out reminders of the testing schedule.

The following schedule is used for each milestone:

Scheduled time Action
7 days before release Pre-reminder for milestone testing
2 to 3 days before release Once appropriate testing area set up, call for testing and start milestone testing
Release day Mark images ready on the ISO tracker once the release team is confident to do so

Package testing

When being used the QA team will schedule package testing sprints to happen during the cycle between milestone testing to ensure applications that are included in Xubuntu have sufficient amount of testing conducted.

Regardless of whether package testing is taking place during a development cycle, additional testing should be conducted for a new default application is to be included in the next Xubuntu release, when an existing application has a substantially large update in the middle of the cycle or when developers request specific testing for a specific update to an application.

Calls for package testing sprints will be sent out as required.

Releasing

When it comes time to deploy a release (both milestones and final) several conditions must be met:

  • Appropriate testing has been done on the image

  • There are no known bugs which cause data loss or damage to hardware

  • The image must not be oversized

  • Xubuntu must be of sufficient quality that it would not damage Xubuntu's, Ubuntu's, or any of the other flavors' reputation/image.

When a release is made, the Xubuntu Release Team must follow the release process specified below. The release process ensures that the new release has sufficient release notes and release announcement and that all release-specific communication is updated to inform about the new release. Where needed, advice from the Ubuntu release team should be asked for.

Scheduled time Action
User Interface Freeze Upload artwork and slideshow packages
Documentation String Freeze Update translation templates
Upload documentation packages
Non-Language Pack Translation Deadline Upload documentation and slideshow packages
14 days before release Reminder to update the website FAQ (final release only)
7 days before release Start preparing release notes and release announcement
Make the tracker start tracking the next release
Release day Publish release announcement and notes
Update the website, IRC channel topics and social media outlets with new release information
After release (final release only) Set the new development version as the default in the tracker
Set up appropriate branches (documentation, ...) in Launchpad
Review and update this page

Maintaining

After a release is made, bugs and problems are bound to be reported. The period between the release and the start of the next release cycle is the optimal time to perform Stable Release Updates (SRU) for major bugs as long as developers do not forget to fix the issue in the next release as well, once the repository opens. Once the next release cycle has started, primary focus will be on the next release and the severity/importance of the SRU candidates will be more important when it comes to deciding whether an SRU will be performed or not.