diff options
Diffstat (limited to 'src/source/code-lines.jd')
| -rw-r--r-- | src/source/code-lines.jd | 68 |
1 files changed, 31 insertions, 37 deletions
diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd index 97a6ca85..95188eef 100644 --- a/src/source/code-lines.jd +++ b/src/source/code-lines.jd @@ -25,10 +25,10 @@ page.title=Codelines, Branches, and Releases </div> <p> - The Android Open Source Project maintains a complete software stack intended to be ported by - OEMs and other device implementors to run on actual hardware. To maintain the quality of - Android, Google has contributed full-time engineers, product managers, UI designers, Quality - Assurance, and all the other roles required to bring modern devices to market. + The Android Open Source Project (AOSP) maintains a complete software stack to be ported by + OEMs and other device implementors and run on their own hardware. To maintain the quality of + Android, Google has contributed full-time engineers, product managers, user interface designers, + quality assurance testers, and all the other roles required to bring modern devices to market. </p> <p> @@ -40,9 +40,8 @@ page.title=Codelines, Branches, and Releases <p> The chart below depicts at a conceptual level how AOSP manages code and releases. We're referring to these as "code lines" instead of "branches" simply because at any given moment - there may be more than one branch extant for a given "code line". For instance, when a - release is cut, sometimes that will become a new branch in git, and sometimes not, based on - the needs of the moment. + there may be more than one branch for a given "code line". For instance, when a + release is cut, it may or may not become a new branch based on the needs of the moment. </p> <ol> <li> @@ -60,14 +59,14 @@ page.title=Codelines, Branches, and Releases <li> <p> In parallel, Google works internally on the next version of the Android platform and - framework, working according to the product's needs and goals. We develop the next + framework according to the product's needs and goals. We develop the next version of Android by working with a device partner on a flagship device whose specifications are chosen to push Android in the direction we believe it should go. </p> </li> <li> <p> - When the "n+1"th version is ready, it will be published to the public source tree, and + When the "n+1"th version is ready, it will be published to the public source tree and become the new latest release. </p> </li> @@ -76,38 +75,32 @@ page.title=Codelines, Branches, and Releases <img src="{@docRoot}images/code-lines.png" alt="code-line diagram"> </p> -<h2 id="notes-and-explanations"> - Notes and Explanations +<h2 id="terms-and-caveats"> + Terms and Caveats </h2> <ul> <li> <p> A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5, - 2.1, and so on. Generally speaking, a release of the platform corresponds to a version of - the <code>SdkVersion</code> field used in AndroidManifest.xml files, and defined in + 2.1, and so on. Generally speaking, a release of the platform corresponds to the version in + the <code>SdkVersion</code> field of AndroidManifest.xml files and defined within <code>frameworks/base/api</code> in the source tree. </p> </li> <li> <p> An <em>upstream</em> project is an open-source project from which the Android stack is - pulling code. These include obvious projects such as the Linux kernel and WebKit, but - over time we are migrating some of the semi-autonomous Android projects (such as Dalvik, + pulling code. These include obvious projects such as the Linux kernel and WebKit. + Over time we are migrating some of the semi-autonomous Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally, these projects are developed entirely in the public tree. For some upstream projects, - development is done by contributing directly to the upstream project itself. See <a href= + development is done by contributing directly to the upstream project itself. See <a href= "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases, snapshots will be periodically pulled into releases. </p> </li> <li> <p> - The diagram refers to "Eclair" and "FroYo"; however, they are simply placeholders, and - the diagram actually reflects the overall release and branching strategy. - </p> - </li> - <li> - <p> At all times, a release code-line (which may actually consist of more than one actual branch in git) is considered the sole canonical source code for a given Android platform version. OEMs and other groups building devices should pull only from a release branch. @@ -115,14 +108,14 @@ page.title=Codelines, Branches, and Releases </li> <li> <p> - We will set up "experimental" code-lines to capture changes from the community, so that - they can be iterated on, with an eye toward stability. + "Experimental" code-lines are established to capture changes from the community so they can + be iterated on with an eye toward stability. </p> </li> <li> <p> - Changes that prove stable will eventually be pulled into a release branch. Note that this - will only apply to bug fixes, app improvements, and other things that do not affect the + Changes that prove stable will eventually be pulled into a release branch. Note this + applies only to bug fixes, application improvements, and other changes that do not affect the APIs of the platform. </p> </li> @@ -135,7 +128,8 @@ page.title=Codelines, Branches, and Releases <li> <p> The "n+1"th version (that is, next major version of the framework and platform APIs) will - be developed by Google internally. See below for details. + be developed by Google internally. See <a href= + "#about-private-code-lines">About Private Codelines</a> for details. </p> </li> <li> @@ -169,23 +163,23 @@ page.title=Codelines, Branches, and Releases </p> <p> OEMs and other device builders naturally want to ship devices with the latest version of - Android. Similarly, application developers don't want to deal with more extant platform + Android. Similarly, application developers don't want to deal with more platform versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic - direction of Android as a platform and a product. Our approach is based on focusing on a - small number of flagship devices to drive features, and secure protections of Android-related - intellectual property. + direction of Android as a platform and a product. Our approach focuses on a small number of + flagship devices to drive features while securing protections of Android-related intellectual + property. </p> <p> - As a result, Google frequently has possession of confidential information of third parties, - and we must refrain from revealing sensitive features until we've secured the appropriate - protections. Meanwhile, there are real risks to the platform arising from having too many + As a result, Google frequently has possession of confidential information from third parties. + And we must refrain from revealing sensitive features until we've secured the appropriate + protections. In addition, there are real risks to the platform arising from having too many platform versions extant at once. For these reasons, we have structured the open-source project -- including third-party contributions -- to focus on the currently-public stable version of Android. "Deep development" on the next version of the platform will happen in - private, until it's ready to become an official release. + private until it's ready to become an official release. </p> <p> - We recognize that many contributors will disagree with this approach. We respect that others - may have a different point of view; however, this is the approach that we feel is best, and + We recognize many contributors will disagree with this approach. We respect others + may have a different point of view; however, this is the approach we feel is best, and the one we've chosen to implement. </p> |