Linking AvailabilityFinder with APIDataSource and intro-table templates.

chrome/common/extensions/docs/templates/json/api_availabilities.json

 {
   "devtools.inspectedWindow": {
     "channel": "stable",
     "version": 18
   },
   "devtools.network": {
     "channel": "stable",
     "version": 18
   },
   "devtools.panels": {
     "channel": "stable",
     "version": 18
   },
+  "storage": {
+    "channel": "stable",
+    "version": 20
+  },

[epeterson, 2013/07/03 19:05:02]

Here's an interesting point with checking availability in versions 18 and 19:

chrome.storage is listed as 20 in its current hardcoded intro-table.

Using AvailabilityFinder, chrome.storage's availability comes out to be 19. This
is because the _features.json files don't have 'channel' information in version
19 and don't exist in version 18.

So, file system existence is used, and storage.json exists in version 19, but
not in 18.

It doesn't seem like there's really a good reference point to use for versions
18 and 19.

[not at google - send to devlin, 2013/07/03 19:54:56]

Ah right. How many does this affect?

[epeterson, 2013/07/09 20:51:18]

Other APIs like browsingData, topSites, privacy, and debugger, fall into the
version 18/19 availability, but comparing these with information listed on the
whats_new page, they appear to have the correct generated availability.

Looking at the pageCapture API, the whats_new page lists it as stable in 18, but
17 is the generated availability, since it shows up in extension_api.json in
version 17 (and I thought that if it wasn't tagged as 'experimental' back in the
extension_api.json days, then it was 'stable').

input.ime is listed as available at 21 in the whats_new page. 
input.ime is experimental in version 17 in extension_api.json, and has a .json
file present up until then, so its given an availability of 18. It was not
represented in _manifest or _permission_features.json. 

Not sure how to get something accurate for cases like this, since there's no
hint as to what channels these APIs are available on before version 20, and
there's not a concrete method to use pre-version 20. This is kind of a letdown.
I apologize.

[epeterson, 2013/07/09 20:51:18]

For reference, here's a list of the API availabilities:

scriptBadge: trunk
declarativeContent: trunk
systemInfo.memory: 29/dev
bluetooth: 29/dev
sessionRestore: 29/dev
systemInfo.cpu: 29/dev
feedbackPrivate: 29/dev
identity: 29/dev
downloads: 28/beta
syncFileSystem: 27
power: 27
usb: 26
systemInfo.display: 26
declarativeWebRequest: 26
tabCapture: 25
commands: 25
pushMessaging: 24
socket: 24
fileSystem: 23
serial: 23
app.window: 23
app.runtime: 23
mediaGalleries: 22
fontSettings: 22
alarms: 22
runtime: 22
events: 21
notifications: 20
browsingData: 19
topSites: 19
storage: 19 (should be 20)
debugger: 18
*devtools.inspectedWindow: 18
input.ime: 18 (should be 21)
privacy: 18
*devtools.panels: 18
*devtools.network: 18
webRequest: 17
pageCapture: 17 (should be 18)
webNavigation: 16
permissions: 16
contentSettings: 16
*webstore: 15
tts: 14
ttsEngine: 14
types: 13
proxy: 13
fileBrowserHandler: 12
omnibox: 9
management: 8
cookies: 6
contextMenus: 6
idle: 6
tabs: 5
pageAction: 5
browserAction: 5
i18n: 5
bookmarks: 5
extension: 5
windows: 5
history: 5

* = predetermined availability, pulled from version of api_availabilities.json
     currently on SVN

[not at google - send to devlin, 2013/07/09 21:07:16]

Heh, not at all, it was pretty undisciplined back then. Perhaps these
restrictions were implemented procedurally or something.

For things as far back s 18/19/20 I think nobody will notice if they're a couple
of versions off, though we should try our best, and yeah if you're not sure then
just be conservative and use the most recent version.

   "webstore": {
     "channel": "stable",
     "version": 15
   }
 }