1 page.title=Codelines, Branches, and Releases 2 @jd:body 3 4 <!-- 5 Copyright 2010 The Android Open Source Project 6 7 Licensed under the Apache License, Version 2.0 (the "License"); 8 you may not use this file except in compliance with the License. 9 You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13 Unless required by applicable law or agreed to in writing, software 14 distributed under the License is distributed on an "AS IS" BASIS, 15 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 See the License for the specific language governing permissions and 17 limitations under the License. 18 --> 19 <div id="qv-wrapper"> 20 <div id="qv"> 21 <h2>In this document</h2> 22 <ol id="auto-toc"> 23 </ol> 24 </div> 25 </div> 26 27 <p> 28 The Android Open Source Project maintains a complete software stack intended to be ported by 29 OEMs and other device implementors to run on actual hardware. To maintain the quality of 30 Android, Google has contributed full-time engineers, product managers, UI designers, Quality 31 Assurance, and all the other roles required to bring modern devices to market. 32 </p> 33 34 <p> 35 Accordingly, we maintain a number of "code lines" to clearly separate the current stable 36 version of Android from unstable experimental work. We roll the open source administration 37 and maintenance of the Android code lines into the larger product development cycle. 38 </p> 39 40 <p> 41 The chart below depicts at a conceptual level how AOSP manages code and releases. We're 42 referring to these as "code lines" instead of "branches" simply because at any given moment 43 there may be more than one branch extant for a given "code line". For instance, when a 44 release is cut, sometimes that will become a new branch in git, and sometimes not, based on 45 the needs of the moment. 46 </p> 47 <ol> 48 <li> 49 <p> 50 At any given moment, there is a current latest release of the Android platform. This 51 typically takes the form of a branch in the tree. 52 </p> 53 </li> 54 <li> 55 <p> 56 Device builders and contributors work with the current latest release, fixing bugs, 57 launching new devices, experimenting with new features, and so on. 58 </p> 59 </li> 60 <li> 61 <p> 62 In parallel, Google works internally on the next version of the Android platform and 63 framework, working according to the product's needs and goals. We develop the next 64 version of Android by working with a device partner on a flagship device whose 65 specifications are chosen to push Android in the direction we believe it should go. 66 </p> 67 </li> 68 <li> 69 <p> 70 When the "n+1"th version is ready, it will be published to the public source tree, and 71 become the new latest release. 72 </p> 73 </li> 74 </ol> 75 <p> 76 <img src="{@docRoot}images/code-lines.png" alt="code-line diagram"> 77 </p> 78 79 <h2 id="notes-and-explanations"> 80 Notes and Explanations 81 </h2> 82 <ul> 83 <li> 84 <p> 85 A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5, 86 2.1, and so on. Generally speaking, a release of the platform corresponds to a version of 87 the <code>SdkVersion</code> field used in AndroidManifest.xml files, and defined in 88 <code>frameworks/base/api</code> in the source tree. 89 </p> 90 </li> 91 <li> 92 <p> 93 An <em>upstream</em> project is an open-source project from which the Android stack is 94 pulling code. These include obvious projects such as the Linux kernel and WebKit, but 95 over time we are migrating some of the semi-autonomous Android projects (such as Dalvik, 96 the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally, 97 these projects are developed entirely in the public tree. For some upstream projects, 98 development is done by contributing directly to the upstream project itself. See <a href= 99 "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases, 100 snapshots will be periodically pulled into releases. 101 </p> 102 </li> 103 <li> 104 <p> 105 The diagram refers to "Eclair" and "FroYo"; however, they are simply placeholders, and 106 the diagram actually reflects the overall release and branching strategy. 107 </p> 108 </li> 109 <li> 110 <p> 111 At all times, a release code-line (which may actually consist of more than one actual 112 branch in git) is considered the sole canonical source code for a given Android platform 113 version. OEMs and other groups building devices should pull only from a release branch. 114 </p> 115 </li> 116 <li> 117 <p> 118 We will set up "experimental" code-lines to capture changes from the community, so that 119 they can be iterated on, with an eye toward stability. 120 </p> 121 </li> 122 <li> 123 <p> 124 Changes that prove stable will eventually be pulled into a release branch. Note that this 125 will only apply to bug fixes, app improvements, and other things that do not affect the 126 APIs of the platform. 127 </p> 128 </li> 129 <li> 130 <p> 131 Changes will be pulled into release branches from upstream projects (including the 132 Android "upstream" projects) as necessary. 133 </p> 134 </li> 135 <li> 136 <p> 137 The "n+1"th version (that is, next major version of the framework and platform APIs) will 138 be developed by Google internally. See below for details. 139 </p> 140 </li> 141 <li> 142 <p> 143 Changes will be pulled from upstream, release, and experimental branches into Google's 144 private branch as necessary. 145 </p> 146 </li> 147 <li> 148 <p> 149 When the platform APIs for the next version have stabilized and been fully tested, Google 150 will cut a release of the next platform version. (This specifically refers to a new 151 <code>SdkVersion</code>.) This will also correspond to the internal code-line being made 152 a public release branch, and the new current platform code-line. 153 </p> 154 </li> 155 <li> 156 <p> 157 When a new platform version is cut, a corresponding experimental code-line will be 158 created at the same time. 159 </p> 160 </li> 161 </ul> 162 163 <h2 id="about-private-code-lines"> 164 About Private Codelines 165 </h2> 166 <p> 167 The source management strategy above includes a code-line that Google will keep private. The 168 reason for this is to focus attention on the current public version of Android. 169 </p> 170 <p> 171 OEMs and other device builders naturally want to ship devices with the latest version of 172 Android. Similarly, application developers don't want to deal with more extant platform 173 versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic 174 direction of Android as a platform and a product. Our approach is based on focusing on a 175 small number of flagship devices to drive features, and secure protections of Android-related 176 intellectual property. 177 </p> 178 <p> 179 As a result, Google frequently has possession of confidential information of third parties, 180 and we must refrain from revealing sensitive features until we've secured the appropriate 181 protections. Meanwhile, there are real risks to the platform arising from having too many 182 platform versions extant at once. For these reasons, we have structured the open-source 183 project -- including third-party contributions -- to focus on the currently-public stable 184 version of Android. "Deep development" on the next version of the platform will happen in 185 private, until it's ready to become an official release. 186 </p> 187 <p> 188 We recognize that many contributors will disagree with this approach. We respect that others 189 may have a different point of view; however, this is the approach that we feel is best, and 190 the one we've chosen to implement. 191 </p> 192
