<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"> <meta name="robots" content="noindex,nofollow"><title>DapperReleaseSchedule - Ubuntu Wiki</title> <link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="DapperReleaseSchedule_files/common.css"> <link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="DapperReleaseSchedule_files/print.css"> <link rel="Start" href="https://wiki.ubuntu.com/FrontPage"> <link rel="Alternate" title="Wiki Markup" href="https://wiki.ubuntu.com/DapperReleaseSchedule?action=raw"> <link rel="Alternate" media="print" title="Print View" href="https://wiki.ubuntu.com/DapperReleaseSchedule?action=print"> <link rel="Search" href="https://wiki.ubuntu.com/FindPage"> <link rel="Index" href="https://wiki.ubuntu.com/TitleIndex"> <link rel="Glossary" href="https://wiki.ubuntu.com/WordIndex"> <link rel="Help" href="https://wiki.ubuntu.com/HelpOnFormatting"></head> <body dir="ltr" lang="en"> <div id="page" dir="ltr" lang="en"> <h1 id="title">DapperReleaseSchedule</h1> <div id="content" dir="ltr" lang="en"> <a id="top"></a> <p><strong>Dapper is a long term supported release, so we need to consider some tweaks to our standard release schedule to make sure we can deliver on the promise of a super-stable and ultra-polished Ubuntu for the masses.</strong> </p> <p>We propose to make the following changes to the process that was followed during the development of Breezy: </p> <h3 id="head-63a5ee5399ec83e4710eddcaa70a2394e7860e6a">The Distro</h3> <ol type="1"> <li><p>We will open up the <strong>entire archive for syncing from upstream, from debian, and other sources</strong>, until <a href="https://wiki.ubuntu.com/UpstreamVersionFreeze">UpstreamVersionFreeze</a>. This is in contrast to an initial proposal only to sync feature goals and universe. Upon analysis, it seems that the benefits of syncing newer packages outweight the number of new bugsthat will inevitably be introduced by the sync. </p> </li> <li class="gap"><p><strong><a href="https://wiki.ubuntu.com/UpstreamVersionFreeze">UpstreamVersionFreeze</a> will be 2 (two) weeks earlier</strong> than it was in Breezy. Of course, feature goals such as Gnome, KDE, Firefox, <a class="nonexistent" href="https://wiki.ubuntu.com/OpenOffice">OpenOffice</a> and other items that are identified up front will continue to sync until their upstream stable release. Note that we will be especially careful with the versions of server products included in the ubuntu-for-servers ISO. The extra two weeks will give us substantial time. Both Main and Universe will observe UVF simultaneously (** see below for discussion of this, it's very much open for debate). </p> </li> <li class="gap"><p>Final release will be <strong>1 (one) week later than usual</strong>, to allow for extra non-invasive polish-only changes, settling, testing, documentation of errata and bugs, and the taking of a collective deep breath before MDZ rolls the ISO's. </p> </li> </ol> <h3 id="head-3beaaf93a9a4b66251ae14375e5ecf54b3432e96">Documentation and Translation</h3> <ol type="1"> <li><p>We will introduce a freeze date for changes to menu structures, application menus, and (broadly) application strings, to allow for the maximum coverage of our translation teams. In addition, we will freeze core documentation to allow for the translation of the documentation itself. </p> </li> </ol> <h3 id="head-dbd651338d8d7a6966bd14ffc6367b3481028548">Hardware Certification</h3> <ol type="1"> <li><p>This release cycle will include a <strong>deadline for hardware certification applications</strong>. We are building a list of specific hardware SKU's (model numbers) on which Dapper will be certified pre-release. We will work to ensure that ALL hardware on that list before the deadline is perfectly detected, configured and activated upon installation. Hardware vendors that join the hardware certification program after that date will have to work towards additional drivers separately installed after the core OS, or custom ISO's that include the extra code needed for the detection and configuration of their hardware. </p> </li> <li class="gap"><p>In addition to the <a href="https://wiki.ubuntu.com/LaptopMission">LaptopMission</a>, which continues into Dapper with even more laptop models formally tested, we will have a specific testing program for servers. The server deadline will be </p> </li> </ol> <h4 id="head-581aa92252c57eb6f05a5cdbc6550117bfcf6ee0">Outstanding Questions</h4> <ul> <li><p> Should Universe freeze later than Main? </p> <ul> <li style="list-style-type: none;"><p><a href="https://wiki.ubuntu.com/MarkShuttleworth">MarkShuttleworth</a>: we have found in the past that newer Universe packages tend to demand newer dependencies in Main. If we ask the MOTU to observe the same <a href="https://wiki.ubuntu.com/UpstreamVersionFreeze">UpstreamVersionFreeze</a> then we will go through the "rush to get the latest thing I care about" at the same time, reducing the risk of tension between Main and Universe post-UVF. Alternatively, we can afford to be more aggressive in Universe, so perhaps we should allow newer versions into universe as long as those do not require newer versions in Main. </p> </li> </ul> </li></ul> <a id="bottom"></a> </div> <p id="pageinfo" class="info" dir="ltr" lang="en">last edited 2005-10-21 19:06:20 by <span title="213.92.82.66">JeffWaugh2</span></p> </div>  </body></html>