pdk/docs/source/code-lines.jd - platform/development - Git at Google

 page.title=Android Code-Lines
 doc.type=source
 @jd:body
 <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.
 Accordingly, we maintain a number of "code lines" to clearly separate the
 current stable version of Android from unstable experimental work.</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>
 <img src="{@docRoot}images/code-lines.png"/>
 <h3>Notes and Explanations</h3>
 <ul>
 <li>A <i>release</i> corresponds to a formal version of the Android platform, such
 as 1.5, 2.0, 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.</li>
 <li>An <i>upstream</i> 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. These will be developed entirely in the public
 tree, and snapshots will be periodically pulled into releases.</li>
 <li>The diagram refers to "Eclair" and "Flan"; however, they are simply
 placeholders, and the diagram actually reflects the overall release and
 branching strategy.</li>
 <li>At all times, the 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. OEMs and other groups building devices
 should pull only from a Release branch.</li>
 <li>We will be setting up an "Experimental" code-line to capture changes from
 the community, so that they can be iterated on, with an eye toward stability.</li>
 <li>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.</li>
 <li>Changes will be pulled into Release branches from upstream projects
 (include the Android "upstream" projects) as necessary.</li>
 <li>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.)</li>
 <li>Changes will be pulled from upstream, Release, and Experimental branches
 into Google's private branch as necessary.</li>
 <li>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.</li>
 <li>When a new platform version is cut, a corresponding Experimental
 code-line.</li>
 </ul>
 <h3>About Private Code-Lines</h3>
 <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 through patents and the like.</p>
 <p>As a result, Google frequently has possession of confidential
 information of third parties, and we must refrain from revealing patentable
 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>
	page.title=Android Code-Lines
	doc.type=source
	@jd:body
	<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.
	Accordingly, we maintain a number of "code lines" to clearly separate the
	current stable version of Android from unstable experimental work.</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>
	<img src="{@docRoot}images/code-lines.png"/>
	<h3>Notes and Explanations</h3>
	<ul>
	<li>A <i>release</i> corresponds to a formal version of the Android platform, such
	as 1.5, 2.0, 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.</li>
	<li>An <i>upstream</i> 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. These will be developed entirely in the public
	tree, and snapshots will be periodically pulled into releases.</li>
	<li>The diagram refers to "Eclair" and "Flan"; however, they are simply
	placeholders, and the diagram actually reflects the overall release and
	branching strategy.</li>
	<li>At all times, the 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. OEMs and other groups building devices
	should pull only from a Release branch.</li>
	<li>We will be setting up an "Experimental" code-line to capture changes from
	the community, so that they can be iterated on, with an eye toward stability.</li>
	<li>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.</li>
	<li>Changes will be pulled into Release branches from upstream projects
	(include the Android "upstream" projects) as necessary.</li>
	<li>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.)</li>
	<li>Changes will be pulled from upstream, Release, and Experimental branches
	into Google's private branch as necessary.</li>
	<li>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.</li>
	<li>When a new platform version is cut, a corresponding Experimental
	code-line.</li>
	</ul>
	<h3>About Private Code-Lines</h3>
	<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 through patents and the like.</p>
	<p>As a result, Google frequently has possession of confidential
	information of third parties, and we must refrain from revealing patentable
	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>