You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 1, 2017. It is now read-only.
Copy file name to clipboardExpand all lines: content/changes/2014-04-22-deprecating-beta-media-type.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author_name: jasonrudolph
5
5
6
6
Now that the GitHub API is[serving the v3 media type by default][v3-default], we are deprecating the legacy[beta media type][beta].
7
7
8
-
We will eventually remove support for the beta media type, but we have no official retirement date toannouce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in[just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.
8
+
We will eventually remove support for the beta media type, but we have no official retirement date toannounce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in[just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.
9
9
10
10
As always, if you have any questions, please[get in touch][contact].
On November 4th, 2014, we will begin sending a new format for[deployment][1] and[deployment status][2] payloads for webhooks. In the meantime we'll be running in acompatability mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.
6
+
On November 4th, 2014, we will begin sending a new format for[deployment][1] and[deployment status][2] payloads for webhooks. In the meantime we'll be running in acompatibility mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.
7
7
8
8
This change brings the payloads for these events more inline with the responses you'd receive from the API. Instead of having deployment and deployment status attributes as top-level keys, we will now nest them under`deployment` and`deployment_status` keys. Since we're still in the[preview period][3] for the deployments API we felt it was best to correct this inconsistency now.
Copy file name to clipboardExpand all lines: content/changes/2015-06-24-licenses-api-update.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Before, license information was only returned for an individual repository:
9
9
10
10
GET /repos/github/hubot
11
11
12
-
Now, license information will also be included inreponses from endpoints that list multiple repositories, such as[List organization repositories](/v3/repos/#list-organization-repositories):
12
+
Now, license information will also be included inresponses from endpoints that list multiple repositories, such as[List organization repositories](/v3/repos/#list-organization-repositories):
Copy file name to clipboardExpand all lines: content/v3/gists.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ The Gist API provides up to one megabyte of content for each file in the gist. E
20
20
21
21
If you need the full contents of the file, you can make a`GET` request to the URL specified by`raw_url`. Be aware that for files larger than ten megabytes, you'll need to clone the gist via the URL provided by`git_pull_url`.
22
22
23
-
In addition to a specific file's contents being truncated, the entire files list may betrucated if the total number exceeds 300 files. If the top level`truncated` key is`true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by`git_pull_url`.
23
+
In addition to a specific file's contents being truncated, the entire files list may betruncated if the total number exceeds 300 files. If the top level`truncated` key is`true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by`git_pull_url`.