s.a.c. redesign, first checkin

Change-Id: I4dead2f18bc5e4a38f204c92198a267c286e775d

1 files changed, 191 insertions, 0 deletions

diff --git a/src/source/code-lines.jd b/src/source/code-lines.jd
new file mode 100644
index 00000000..e37e0cc8
--- /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