Go-github: Update Protected Branches API preview

[gmlewis]

GitHub Announcement:
https://developer.github.com/changes/2017-04-11-protected-branch-dismissal-restrictions/

Note that the provided link in the announcement is somewhat misleading in that this change affects potentially more than just this one API endpoint on this page.

I think the point is to ensure that dismissal_restrictions is handled properly.

[jkosecki]

I can work on this. @gmlewis, please assign it to me

[gmlewis]

Please also check out the latest GitHub Developer announcement about this API:
https://developer.github.com/changes/2017-04-20-protected-branches-dismiss-stale-review/
If you can incorporate these changes as well, it seems reasonable to me to do so within the same PR since it is the same preview API.

If not, though, that is fine too and we can open up a new issue for it.

[jkosecki]

@gmlewis No problem, I'll bring this changes as well, no need to create another issue

[gmlewis]

There is yet another GitHub Developer announcement about breaking changes to this API:
https://developer.github.com/changes/2017-05-02-adoption-of-admin-enforced/

[gmlewis]

There is another announcement for this API:
https://developer.github.com/changes/2017-06-16-loki-preview-ending-soon/

[gmlewis]

I believe that this issue is still open, so I didn't close it with #637.
Please correct me if I'm wrong as I haven't done a thorough investigation at this point.

[elliott-beach]

The Jun 22 announcement did not introduce new changes, but it means we can remove the special accept header for the API preview on Sept 1st.

To elaborate on the gory details of the announcement, the functions related to protected branches such as updateBranchProtection already work in the way described in the announcement. The update endpoint uses the PUT method, and we have a requiredPullRequestReview property of the struct which the client can populate. https://github.com/google/go-github/blob/fe4b6036cb400908b8903d3df9444b9599a60d57/github/repos.go#L773-774.

I can take of care of removing the accept header, although it is a very simple change.

[gmlewis]

While here, @e-beach, can you determine if removing the API preview accept header would affect Enterprise API clients? I seem to recall that if you are not a GitHub Enterprise customer, that you don't have access to the Enterprise API docs, but this was a long time ago and I could be mistaken. We just had a discussion about this in #638.

[elliott-beach]

@gmlewis I couldn't tell. I suspect we must wait and see until the documentation is updated, either in the current release, 2.10, or in a new release.

The enterprise docs are available at https://developer.github.com/enterprise/2.10/v3/, and there's contextual information and a list of releases at https://developer.github.com/v3/enterprise/.

It seems correct to not use those above commits of mine until we know for certain that the change is supported on Enterprise.

[gmlewis]

Latest announcement from GitHub:
https://developer.github.com/changes/2017-09-06-protected-branches-preview-end/

It is still not clear to me if this equally applies to Enterprise customers.
Maybe an Enterprise customer could comment.

[elliott-beach]

Actually, documentation on this is available here for the most recent version of GitHub Enterprise: https://developer.github.com/enterprise/2.10/v3/repos/branches/#response-1. It still lists the API as in preview mode.

My understanding is that, because GitHub Enterprise is locally hosted by the enterprise, enterprise customers have to upgrade their infrastructure to receive new updates - it doesn't happen automatically. GitHub has to release a new version of the Enterprise API, and customers have to upgrade to the new version. So it would be best to maintain the preview header for some time yet.

[dmitshur]

My understanding is that, because GitHub Enterprise is locally hosted by the enterprise, enterprise customers have to upgrade their infrastructure to receive new updates - it doesn't happen automatically. GitHub has to release a new version of the Enterprise API, and customers have to upgrade to the new version. So it would be best to maintain the preview header for some time yet.

Right. But we still need to have some goal that we can target. I think it should be the latest Enterprise version that's available. When it no longer requires the preview header, that's when we can remove it.

The idea is that those who are using latest enterprise version can use latest version of go-github. Others should use an older version via vendoring and update when they update their enterprise version.

If we don't have a clear goal of when we can remove preview headers, it would become very hard to know when to remove them. They would accumulate and begin to cause issues and increased maintenance and development cost.