Android release process
Viral Mehta
--
Thanks,
Viral Mehta
Deva R
android.git.kernel.org
> So, if I have Android repo cloned on my machine and I am regularly pulling
> it. If some day, Google releases next version of Android, will HEAD of my
> cloned repo and Google release will be identical ?
./.repo/projects will have complete data base till that moment of your
exisiting projects (all gits, with their eclair,froyo,.. branches)
on new pastry release, most likely all projects will get a new
<honeycomb> branch, and probably new projects are added too.
so, on top of it, if you take care of your ./.repo/manifest.xml to
point proper android release, and do repo sync => it will be
incremetal pull.
> --
> unsubscribe: android-porti...@googlegroups.com
> website: http://groups.google.com/group/android-porting
>
--
Regards,
Deva
www.bittoggler.com
vkmgeek
On Feb 1, 3:41 pm, Deva R <r.deva...@gmail.com> wrote:
> >DoesAndroidreleasehappen from publically viewed Master branch of repo/git ?
> > So, if I haveAndroidrepo cloned on my machine and I am regularly pulling
> > it. If some day, Google releases next version ofAndroid, will HEAD of my
> > cloned repo and Googlereleasewill be identical ?
> ./.repo/projects will have complete data base till that moment of your
> exisiting projects (all gits, with their eclair,froyo,.. branches)
For e.g., when HoneyComb branch was created?
As soon as GingerBread is released or any time later
> so, on top of it, if you take care of your ./.repo/manifest.xml to
> point proper android release, and do repo sync => it will be
> incremetal pull.
Will that code merged to public master when release happens ?
Jean-Baptiste Queru
We (Google) have a set of internal git servers where we do our
internal development.
We have a master branch internally, which is where the longest-term
work happens. All changes made inside Google and all AOSP
contributions end up in that master branch, i.e. it's the
downstream-most branch as far as Google is concerned, and typically
the least stable one too.
At some points in development, there's a need to stabilize for one
series of releases while making potentially destabilizing changes for
later releases. At that point we branch from our internal master
branch into a named branch (e.g. gingerbread). The named branch is
always created months in advance of the first official release from
that release family.
Along with that named branch, we create a matching release branch that
we build from changes done in the named branch (i.e.
gingerbread-release to match the gingerbread branch). That's the
branch that official releases come from (SDK images, system images for
Nexus phones).
When the source code for a given release is ready to be released, we
open-source the open-sourceable part of the release branch, the
matching state of the named branch, and we merge the named branch into
the AOSP master branch. The AOSP master branch contains the merged sum
of all the available AOSP changes.
At the platform level, all projects are branched for all releases,
even when we don't anticipate the need to make changes in all
projects. It's simpler that way.
JBQ
> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.