en/setup/start/codelines.html - platform/docs/source.android.com - Git at Google

 <html devsite>
   <head>
     <title>Codelines, Branches, and Releases</title>
     <meta name="project_path" value="/_project.yaml" />
     <meta name="book_path" value="/_book.yaml" />
   </head>
   <body>
   <!--
       Copyright 2017 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.
   -->

 <p>
   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>
   Accordingly, we maintain a number of codelines to clearly separate the current
   stable version of Android from unstable experimental work. We roll the open
   source administration and maintenance of the Android codelines into the larger
   product development cycle.
 </p>

 <h2 id="aosp-management">AOSP code management</h2>
 <p>
   The chart below depicts the concepts behind AOSP code management and releases.
 </p>

 <img src="/images/code-lines.png" alt="codeline diagram" id="figure1" >
 <figcaption><strong>Figure 1.</strong> AOSP code and releases</figcaption>

 <ol>
   <li>
 	  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.
   </li>
   <li>
 	  Device builders and contributors work with the current latest release,
     fixing bugs, launching new devices, experimenting with new features, and so on.
   </li>
   <li>
 	  In parallel, Google works internally on the next version of the Android
     platform and 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.
 	</li>
   <li>
 	  When the n+1th version is ready, it's published to the public source
     tree and becomes the new latest release.
   </li>
 </ol>

 <aside class="note"><strong>Note:</strong> We use the term <em>codelines</em>
   instead of <em>branches</em> simply because at any given moment there may be
   more than one branch for a given codeline. For instance, when a release is
   cut, it may or may not become a new branch based on the needs of the moment.
 </aside>


 <h2 id="terms-and-caveats">Terms and caveats</h2>

 <ul>
   <li>
 	  A <em>release</em> corresponds to a formal version of the Android platform,
     such as 1.5 or 8.1. A release of the platform corresponds to the
     version in the <code>SdkVersion</code> field of
     <code>AndroidManifest.xml</code> files and defined within
     <code>frameworks/base/api</code> in the source tree.
   </li>
   <li>
 	  An <em>upstream</em> project is an open source project from which the
     Android stack pulls code. In addition to projects such as the Linux kernel
     and WebKit, we continue to migrate some semi-autonomous Android projects
     such as ART, the Android SDK tools, and Bionic to work as
     upstream projects. Generally, these projects are developed entirely in the
     public tree. For some upstream projects, developers contribute
     directly to the upstream project. For details, see
     <a href="../contribute/submit-patches.html#upstream-projects">Upstream
     projects</a>. In both cases, snapshots are periodically pulled into
     releases.
   </li>
   <li>
 	  At all times, a release codeline (which may consist of more than
     one 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.
   </li>
   <li>
 	  Experimental codelines are established to capture changes from the community
     so that they can be iterated on with an eye toward stability.
   </li>
   <li>
 	  Changes that prove stable are eventually pulled into a release branch.
     This applies only to bug fixes, application improvements, and other changes
     that don't affect the APIs of the platform.
   </li>
   <li>
 	  Changes are pulled into release branches from upstream projects
     (including the Android upstream projects) as necessary.
   </li>
   <li>
 	  The n+1th version (the next major version of the framework and platform
     APIs) is developed by Google internally. For details, see
     <a href="#private-codelines">Private codelines</a>.
   </li>
   <li>
 	  Changes are pulled from upstream, release, and experimental branches into
     Google's private branch as necessary.
   </li>
   <li>
 	  When the platform APIs for the next version are stabilized and fully
     tested, Google cuts a release of the next platform version (specifically, a
     new <code>SdkVersion</code>). This corresponds to the internal codeline
     being made a public release branch and the new current platform codeline.
   </li>
   <li>
 	  When a new platform version is cut, a corresponding experimental codeline is
     created at the same time.
   </li>
 </ul>

 <h2 id="private-codelines">Private codelines</h2>
 <p>
   The source management strategy above includes a codeline that Google keeps
   private 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 platform versions than necessary. Meanwhile, Google retains
   responsibility for the strategic 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 from
   third parties and must refrain from revealing sensitive features until
   securing the appropriate protections. In addition, there are real risks to the
   platform if too many platform versions are extant at one time. 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 occurs in
   private until it's ready to become an official release.
 </p>
 <p>
   We recognize that many contributors disagree with this approach and we respect
   their points of view. However, this is the approach we feel is best
   and the one we've chosen to implement for Android.
 </p>

   </body>
 </html>
	<html devsite>
	<head>
	<title>Codelines, Branches, and Releases</title>
	<meta name="project_path" value="/_project.yaml" />
	<meta name="book_path" value="/_book.yaml" />
	</head>
	<body>
	<!--
	Copyright 2017 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.
	-->

	<p>
	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>
	Accordingly, we maintain a number of codelines to clearly separate the current
	stable version of Android from unstable experimental work. We roll the open
	source administration and maintenance of the Android codelines into the larger
	product development cycle.
	</p>

	<h2 id="aosp-management">AOSP code management</h2>
	<p>
	The chart below depicts the concepts behind AOSP code management and releases.
	</p>

	<img src="/images/code-lines.png" alt="codeline diagram" id="figure1" >
	<figcaption><strong>Figure 1.</strong> AOSP code and releases</figcaption>

	<ol>
	<li>
	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.
	</li>
	<li>
	Device builders and contributors work with the current latest release,
	fixing bugs, launching new devices, experimenting with new features, and so on.
	</li>
	<li>
	In parallel, Google works internally on the next version of the Android
	platform and 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.
	</li>
	<li>
	When the n+1th version is ready, it's published to the public source
	tree and becomes the new latest release.
	</li>
	</ol>

	<aside class="note"><strong>Note:</strong> We use the term <em>codelines</em>
	instead of <em>branches</em> simply because at any given moment there may be
	more than one branch for a given codeline. For instance, when a release is
	cut, it may or may not become a new branch based on the needs of the moment.
	</aside>


	<h2 id="terms-and-caveats">Terms and caveats</h2>

	<ul>
	<li>
	A <em>release</em> corresponds to a formal version of the Android platform,
	such as 1.5 or 8.1. A release of the platform corresponds to the
	version in the <code>SdkVersion</code> field of
	<code>AndroidManifest.xml</code> files and defined within
	<code>frameworks/base/api</code> in the source tree.
	</li>
	<li>
	An <em>upstream</em> project is an open source project from which the
	Android stack pulls code. In addition to projects such as the Linux kernel
	and WebKit, we continue to migrate some semi-autonomous Android projects
	such as ART, the Android SDK tools, and Bionic to work as
	upstream projects. Generally, these projects are developed entirely in the
	public tree. For some upstream projects, developers contribute
	directly to the upstream project. For details, see
	<a href="../contribute/submit-patches.html#upstream-projects">Upstream
	projects</a>. In both cases, snapshots are periodically pulled into
	releases.
	</li>
	<li>
	At all times, a release codeline (which may consist of more than
	one 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.
	</li>
	<li>
	Experimental codelines are established to capture changes from the community
	so that they can be iterated on with an eye toward stability.
	</li>
	<li>
	Changes that prove stable are eventually pulled into a release branch.
	This applies only to bug fixes, application improvements, and other changes
	that don't affect the APIs of the platform.
	</li>
	<li>
	Changes are pulled into release branches from upstream projects
	(including the Android upstream projects) as necessary.
	</li>
	<li>
	The n+1th version (the next major version of the framework and platform
	APIs) is developed by Google internally. For details, see
	<a href="#private-codelines">Private codelines</a>.
	</li>
	<li>
	Changes are pulled from upstream, release, and experimental branches into
	Google's private branch as necessary.
	</li>
	<li>
	When the platform APIs for the next version are stabilized and fully
	tested, Google cuts a release of the next platform version (specifically, a
	new <code>SdkVersion</code>). This corresponds to the internal codeline
	being made a public release branch and the new current platform codeline.
	</li>
	<li>
	When a new platform version is cut, a corresponding experimental codeline is
	created at the same time.
	</li>
	</ul>

	<h2 id="private-codelines">Private codelines</h2>
	<p>
	The source management strategy above includes a codeline that Google keeps
	private 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 platform versions than necessary. Meanwhile, Google retains
	responsibility for the strategic 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 from
	third parties and must refrain from revealing sensitive features until
	securing the appropriate protections. In addition, there are real risks to the
	platform if too many platform versions are extant at one time. 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 occurs in
	private until it's ready to become an official release.
	</p>
	<p>
	We recognize that many contributors disagree with this approach and we respect
	their points of view. However, this is the approach we feel is best
	and the one we've chosen to implement for Android.
	</p>

	</body>
	</html>