Skip to content

New API Version #4077

Open
Open

Description

@deiga

A new API version just dropped: https://github.blog/changelog/2026-03-12-rest-api-version-2026-03-10-is-now-available/

What kind of a path forward do you envision for this?

Should the library provide support for bott versions for a while going forward? Or would you want to wait before adopting the new API version?

I could be interested to implement some of the changes, but having a discussion about How sounds reasonable to me first ☺️

Activity

  1. gmlewis commented on Mar 12, 2026

    @gmlewis
    Collaborator

    We have discussed API versioning in this repo before and are planning on supporting it, as mentioned in our README.md.
    I have to step away, but Yes, we plan on supporting it, and you are welcome to start working on it.
    It might be nice to have a checkbox list of endpoints that need addressing, and we can check them off as we go.

  2. stevehipwell commented on Mar 12, 2026

    @stevehipwell
    Contributor

    @gmlewis step away?

  3. gmlewis commented on Mar 13, 2026

    @gmlewis
    Collaborator

    @gmlewis step away?

    I'm back. 😂

  4. deiga commented on Mar 13, 2026

    @deiga
    ContributorAuthor

    We have discussed API versioning in this repo before and are planning on supporting it, as mentioned in our README.md.
    I have to step away, but Yes, we plan on supporting it, and you are welcome to start working on it.
    It might be nice to have a checkbox list of endpoints that need addressing, and we can check them off as we go.

    🤦‍♂️ I just assumed there is no prior art because I didn't find an issue, sorry.

    The Readme does cover it nicely already.
    I volunteer creating that tracking issue, but I'm on holiday this weekend. If anyone else wants to create it before I get to it, I won't mind

  5. gmlewis commented on Mar 13, 2026

    @gmlewis
    Collaborator

    I volunteer creating that tracking issue, but I'm on holiday this weekend. If anyone else wants to create it before I get to it, I won't mind

    Wonderful, thank you, @deiga! Have a great holiday, and we look forward to your contributions when you come back!

  6. maishivamhoo123 commented on Mar 15, 2026

    @maishivamhoo123
    Contributor

    Tracking List

    Reference :- https://docs.github.com/en/rest/about-the-rest-api/breaking-changes?apiVersion=2026-03-10#upgrading-to-a-new-api-version

    • GET /rate_limit: Remove deprecated rate property (read from resources.core instead).
    • POST /orgs/{org}/teams: Remove deprecated permission property from requests.
    • GET /repos/{owner}/{repo}/contents/{path}: Update parsing so submodules return type: "submodule" instead of "file".
    • SARIF responses: Fix Content-Type handling to expect application/sarif+json (instead of application/json+sarif).
    • Repository objects (Settings): Replace use_squash_pr_title_as_default property with squash_merge_commit_title across all endpoints returning repository payloads.
    • GET / (API root): Remove authorizations_url property from the response object.
    • Legacy beta media type: Remove all legacy field support across affected endpoints (e.g., flat emails array, null pull request defaults, user -> owner, master_branch -> default_branch).
    • Gists: Remove history and forks properties from the base-gist object across all Gist endpoints.
    • DELETE /app/installations/{installation_id}: Update expected success status code from 204 to 202.
    • GET /orgs/{org} & PATCH /orgs/{org}: Remove secret_scanning_push_protection_custom_link_enabled from requests and responses.
    • GET /repos/{owner}/{repo}/code-scanning/default-setup: Replace javascript and typescript enum values with the combined javascript-typescript value.
    • Repository objects (General): Remove deprecated has_downloads property across all endpoints returning repository payloads.
    • POST /orgs/{org}/repos & POST /user/repos: Change expected trade control error code from 422 to 451.
    • DELETE /orgs/{org}: Change expected trade control error code from 403 to 451.
    • DELETE /orgs/{org}/members/{username}: Change expected trade control error code from 403 to 451.
    • PUT /orgs/{org}/memberships/{username}: Change expected trade control error code from 403 to 451.
    • PATCH /user/repository_invitations/{invitation_id}: Change expected trade control error code from 403 to 451.
    • GET / (API root): Remove deprecated hub_url property from the response object.
    • Security Advisories: Replace the cvss property with cvss_severities across all advisory endpoints.
    • Migrations: Remove repository detail fields from all migration resource responses.
    • /hub endpoint: Completely remove support for this deprecated endpoint.
    • Pull Request objects: Remove the merge_commit_sha field from all PR response payloads.
    • POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches: Remove return_run_details parameter, change success code from 204 to 200, and parse workflow run details from the response body.
    • Issue & PR objects: Remove the singular assignee field (ensure we only use the assignees array).
    • PUT /orgs/{org}/dependabot/secrets/{secret_name}: Ensure selected_repository_ids parameter only accepts integers.
    • Attestations: Remove the bundle property from attestation list responses (users should use bundle_url instead).
  7. gmlewis commented on Mar 15, 2026

    @gmlewis
    Collaborator

    Awesome, @maishivamhoo123 ... thank you!

    To everyone: if you would like to work on one or more of these checkboxes, please mention that in this issue so that we don't duplicate effort. Thank you for your contributions!

  8. deleted a comment from Roemer on Apr 9, 2026
  9. deleted a comment from Roemer on Apr 9, 2026
  10. keeltrace commented on Sep 7, 2026

    @keeltrace
    Contributor

    I plan to take the Issue & PR objects singular assignee checklist item. Given the GHES compatibility guidance on #4098, I will keep the fields for older servers and scope the change to marking the core Issue.Assignee and PullRequest.Assignee fields deprecated in favor of Assignees, rather than removing them.

  11. keeltrace commented on Sep 7, 2026

    @keeltrace
    Contributor

    I plan to take the DELETE /app/installations/{installation_id} 2026-03-10 migration checkbox. I will keep it narrowly scoped to accepting the endpoint new 202 success response and updating its regression coverage, without changing unrelated App APIs.

  12. keeltrace commented on Sep 8, 2026

    @keeltrace
    Contributor

    I plan to take the Attestations 2026-03-10 migration checklist item. I’ll keep it narrowly scoped to preserving compatibility with older GitHub/GHES responses while adding support for the new bundle_url response field, with regression coverage for both shapes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions