s.a.c. redesign, first checkin
Change-Id: I4dead2f18bc5e4a38f204c92198a267c286e775d
diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd
new file mode 100644
index 0000000..e37e0cc
--- /dev/null
+++ b/src/source/code-lines.jd
@@ -0,0 +1,191 @@
+page.title=Codelines, Branches, and Releases
+@jd:body
+
+<!--
+ Copyright 2010 The Android Open Source Project
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</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.
+</p>
+
+<p>
+ Accordingly, we maintain a number of "code lines" to clearly separate the current stable
+ version of Android from unstable experimental work. We roll the open source administration
+ and maintenance of the Android code lines into the larger product development cycle.
+</p>
+
+<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.
+</p>
+<ul>
+ <li>
+ <p>
+ At any given moment, there is a current latest release of the Android platform. This
+ typically takes the form of a branch in the tree.
+ </p>
+ </li>
+ <li>
+ <p>
+ Device builders and contributors work with the current latest release, fixing bugs,
+ launching new devices, experimenting with new features, and so on.
+ </p>
+ </li>
+ <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
+ 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
+ become the new latest release.
+ </p>
+ </li>
+</ul>
+<p>
+ <img src="{@docRoot}images/code-lines.png" alt="code-line diagram">
+</p>
+
+<h2 id="notes-and-explanations">
+ Notes and Explanations
+</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
+ <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,
+ 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=
+ "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.
+ </p>
+ </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.
+ </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
+ APIs of the platform.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled into release branches from upstream projects (including the
+ Android "upstream" projects) as necessary.
+ </p>
+ </li>
+ <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.
+ </p>
+ </li>
+ <li>
+ <p>
+ Changes will be pulled from upstream, release, and experimental branches into Google's
+ private branch as necessary.
+ </p>
+ </li>
+ <li>
+ <p>
+ When the platform APIs for the next version have stabilized and been fully tested, Google
+ will cut a release of the next platform version. (This specifically refers to a new
+ <code>SdkVersion</code>.) This will also correspond to the internal code-line being made
+ a public release branch, and the new current platform code-line.
+ </p>
+ </li>
+ <li>
+ <p>
+ When a new platform version is cut, a corresponding experimental code-line will be
+ created at the same time.
+ </p>
+ </li>
+</ul>
+
+<h2 id="about-private-code-lines">
+ About Private Codelines
+</h2>
+<p>
+ The source management strategy above includes a code-line that Google will keep private. The
+ reason for this is to focus attention on the current public version of Android.
+</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
+ 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.
+</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
+ 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.
+</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
+ the one we've chosen to implement.
+</p>
\ No newline at end of file