Announce plans to fix type value for submodules

jasonrudolph · jasonrudolph · commit 1b329b04cece · 2013-04-30T05:24:41.000-04:00
Prior to 2013-04-30, you could not GET a submodule via the Repository Contents API. (You could see the submodule listed when you GET the directory that the submodule resides it, but you could not GET just the submodule.) On 2013-04-30, we added the ability to GET a submodule. (See 81c7e58.) When you GET a submodule, the "type" is returned as "submodule". Prior to 2013-04-30, when you listed the contents of a directory using the Repository Contents API, the output included submodules, but it returned the "type" as "file". The type *should* be "submodule". We are leaving this behavior as is for v3, so as not to break any client code that might depend on this behavior. In the next major version of the API, the type will be returned as "submodule".
diff --git a/content/index.md b/content/index.md
@@ -46,6 +46,7 @@ objects.
 * `[ ]` Use JSON to POST to the "repos/:owner/:repo/forks" endpoint, instead of a query string.
 * `[✓]` <del>User Emails come back [as a hash][v3-email] instead of a string.</del>
 * `[ ]` Remove the unused "bio" field for Users.
+* `[ ]` When listing the contents of a directory in the [Repository Contents API](/v3/repos/contents/#get-contents), fix the `type` value returned for submodules: change the value to `"submodule"` (instead of `"file"`).
 
 ### Breaking Beta Changes
 
