Removing references to legacy packaged apps across extension docs.

chrome/common/extensions/docs/server2/templates/articles/autoupdate.html

 <h1>Autoupdating</h1>
 
 
 <p>We want extensions to be autoupdated for some of the same reasons as Google Chrome itself: to incorporate bug and security fixes, add new features or performance enhancements, and improve user interfaces.</p>
 
 <p>If you publish your extension using the <a href="https://chrome.google.com/webstore/developer/dashboard">Chrome Developer Dashboard</a>, you can <em>ignore this page</em>. You can use the dashboard to release updated versions of your extension to users, as well as to the Chrome Web Store.</p>
 
 <p>If you want to host your extension somewhere other than the store, keep reading.
 You should also read <a href="hosting.html">Hosting</a> and
 <a href="packaging.html">Packaging</a>.</p>
@@ skipping 32 matching lines @@
 
 <p>This XML format is borrowed from that used by Omaha, Google's update infrastructure. See <a href="http://code.google.com/p/omaha/">http://code.google.com/p/omaha/</a> for more details.
 The extensions system uses the following attributes
 for the <strong>&lt;app></strong>
 and <strong>&lt;updatecheck></strong> elements of the update manifest:
 </p>
 
 <p><b>appid</b><br>
 The extension ID, generated based on a hash of the extension's public key,
 as described in <a href="packaging.html">Packaging</a>. You can find the
-ID of an extension or packaged app by going to the Extensions page (<b>chrome://extensions</b>).
-
-Hosted apps, however, are not listed on the Extensions page.  You can find the ID of any

[Mihai Parparita -not on Chrome, 2012/09/16 04:55:02]

Hosted apps are not (publicly) deprecated yet, we shouldn't remove references to
them.

[Aaron Boodman, 2012/09/17 21:23:08]

Again, this caveat is something that should only be shown for the apps
documentation, I think.

Here's an example:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs...
-- {{?is_apps}}

[mkearney1, 2012/09/17 21:30:17]

Yes, we need the apps stuff to be in apps docs-- it's very confusing talking
about extensions, apps, and hosted apps in same breadth. I have a recommendation
for the manifest which I will send in a separate email to you both. It's not
going to answer every cross-over instance though.
On 2012/09/17 21:23:08, Aaron Boodman wrote:

-app using the following steps:
+ID of an extension by going to the Extensions page (<b>chrome://extensions</b>).

[Aaron Boodman, 2012/09/16 00:44:35]

What did we decide to do about pages like this that describe concepts that are
common to all types of packages?

[Mihai Parparita -not on Chrome, 2012/09/16 04:55:02]

Given that this page appears in the apps doc set too
(http://developer.chrome.com/apps/autoupdate.html), I think the reference to
packaged apps can stay (it's equally applicable to both legacy and platform
apps).

[Aaron Boodman, 2012/09/17 21:18:04]

Yeah. My question was what we decided to do in the long term.

I keep coming back to the idea that we should factor out the concepts that are
common to all Chrome package types into some separate section, like
developer.chrome.com/packages. It would have its own landing page and would
describe everything that is common between themes, extensions, hosted apps,
legacy packaged apps, and packaged apps, along with any other new types we
introduce over time.

Then /extensions/manifest.html, for example, would just list the keys that are
specific to extensions, and would include a link to /package/manifest.html.

For the specific case of autoupdate, I'm not even sure if we even need an
extensions and apps specific page. We'd just point to the one at
/packages/autoupdate.html.

That said, for now, can we branch on whether this is for extensions and packaged
apps and use the right words, rather than saying 'extension or packaged app'? I
thought we had support for that.

[mkearney1, 2012/09/17 21:30:17]

I have a to-do to investigate if there are any special circumstances for
autoupdating apps. Assuming there are, then it would seem like we should be very
clear about these. If there aren't, then we could just keep this as is.

On 2012/09/16 04:55:02, Mihai Parparita wrote:

 </p>
 
-<ul>
-  <li> Open the app. You can do this by clicking its icon on the New Tab page.</li>
-  <li> Open the JavaScript console.  You can do this by clicking the wrench icon
-       and choosing <b>Tools &gt; JavaScript Console</b>.</li>
-  <li> Enter the following expression into the JavaScript console: <code>chrome.app.getDetails().id</code>
-      <p>The console shows the app's ID as a quoted string.</p>
-  </li>
-</ul>
-
 <p><b>codebase</b><br>
 A URL to the extension's <code>.crx</code> file.</p>
 
 <p><b>version</b><br>
 Used by the client to determine whether it should download the <code>.crx</code> file specified by <code>codebase</code>. It should match the value of "version" in the <code>.crx</code> file's <code>manifest.json</code> file.</p>
 <p>The update manifest XML file may contain information about multiple extensions by including multiple &lt;app&gt; elements.</p>
 
 
 <h2>Testing</h2>
 <p>The default update check frequency is several hours,
@@ skipping 63 matching lines @@
 
 <pre>&lt;?xml version='1.0' encoding='UTF-8'?&gt;
 &lt;gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'&gt;
 &nbsp;&nbsp;&lt;app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'&gt;
 &nbsp;&nbsp; &nbsp;&lt;updatecheck&nbsp;codebase='http://myhost.com/mytestextension/mte_v2.crx'&nbsp;version='2.0' <b>prodversionmin='3.0.193.0'</b>/&gt;
 &nbsp;&nbsp;&lt;/app&gt;
 &lt;/gupdate&gt;
 </pre>
 
 <p>This would ensure that users of this extension would autoupdate to version 2 only if they are running Google Chrome 3.0.193.0 or greater.</p>