Removing support for channel=master broke Flutter's API docs

[goderbauer]

In Flutter's API docs we are passing channel=master as a query param to dart pad to run sample code on the master/main branch. This broke recently when channel=master instead gave us the stable channel. Instead of master, main needs to be passed in now. We are fixing this in flutter/flutter#144329.

This breakage went undetected for some time. I am wondering if there is something we can do to avoid breaking Flutter's API docs on these kind of dart pad changes. This issue is meant as a starting point for that discussion.

[lrhn]

If there are external uses of the URI-based API, then it should probably be considered an API, with "versioning" and breaking change policies.

Seeing it that way would likely have made the transition more explicit and visible:

• A public "breaking change" notification, with a schedule and deprecation period.
• A temporary support for channel=master where using it shows a warning banner on the page, maybe or maybe not with a HTTP redirect (say to same URI with channel=masterchanged tochannel=main&deprecation=master-channel`, or something, which could use that URI to trigger showing the warning).
  That could then allow automatic testing of URIs at the Flutter end, checking if the URIs they expose do not get a "permanent redirect" HTTP response, which would be a signal to update the URIs.

Since there is only one implementation, "versioning" isn't really the correct word. The version you get is the version that is live today. But explicit breaking changes, with public schedules and deprecations, can still work.

[parlough]

To note, in relation to this specific case, I think we intended to keep master working for the API docs, but missed this case. fb56528 fixes this.

For large changes, I generally verify they don't cause issues for the Flutter API docs locally, but that's not super sustainable. Perhaps we can require a more explicit consideration.