tauntz wrote: > Did you just say that Google is not pushing code/releases to tmo
Of course Google doesn't push code/releases to T-Mobile. T-Mobile is a mobile carrier. > and > that tmo pulls the public source at random points in time, adds dream > specific bits and releases it to end-users? HTC pulls source at whatever time schedule they deem appropriate. HTC engineers are working on the code constantly and can make their own decisions vis a vis their product lines. Neither you nor I, nor possibly Google, is in position to tell HTC what they can or cannot do. Now, if HTC is sensible, they will primarily stick to major releases plus milestone bug fix updates, but that's not something you should be relying upon. > You do realize that all > releases till today have come from a closed source project and not > AOSP? HTC may have access to a private *repository*, but AFAIK, the bits are still open source. Open source is a matter of licensing, not a statement of public collaborative development. > (Even if Google doesn't actually push the code/release to tmo, they > certainly do tell tmo (and other carriers) when the code in the repo > is "stable enough" so they can pull and release. I certainly would hope so. > What I'm asking for, > is that at this point in time (eg Google has designated the code as > "stable enough to release") we get an official SDK - is that too much > to ask?) Of course it is. A "point in time" is infinitesimally short. Assuming you were being loose with your terms, how long would you consider a "point in time" to be? A second? A minute? An hour? A day? A week? A month? A year? Let us suppose that they tag whatever repository HTC works from for each major release. Once they tag the firmware release -- in effect, designating the code as "stable enough to release" -- they still need to build, test, fix, package, and release the SDK. That will take some time, even if they have been doing some of that work along the way, because up until now, the firmware has been a moving target, and the apps that ship with the firmware are not built on the SDK. For example, they may not test on Windows routinely due to the hassles involved in building the Windows version of the SDK. Should that take months? No. Might it take weeks? Possibly, depending on what is all involved and how many people are doing the work. Now, the *right* answer is for this to be a true public collaborative development project, so nightly builds of emulator images and corresponding SDKs are available, so we can apply tinderbox and smoke testing sessions and the like. In time, we should be able to cut the time between tagging the final shipping firmware and releasing the corresponding SDK with emulator images to be hours, not weeks. And perhaps it's at that level already, and I just haven't seen it since we haven't had all that many releases yet. But this still does not prevent hardware manufacturers from doing what they want. As evidenced by "pre-N" wireless routers, hardware manufacturers are not necessarily constrained by what would seem to be common sense to us out here. They'll do what they do. So if a device (e.g., G2) contains bits of cupcake in advance of an official cupcake-based release shipping, that was the manufacturer's decision. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
