Automate release branch creation

[DanielRosenwasser]

We need to perform the following tasks every time we create a release-*.* branch:

1. TypeScript creates a branch from master on GitHub.
2. TypeScript updates the version on that branch to beta.
   1. Update package.json
   2. Update src/compiler/corePublic.ts
3. TypeScript LKGs the branch.
4. SDK script is updated to sync from that branch.

We should find a way to do all of this "at once".

[orta]

Could the creation of the tag on the repo be the trigger for this? I've done this kind of stuff with Danger ( https://github.com/danger/peril-settings/blob/master/org/new_tag.ts )

[uniqueiniquity]

I think the tag happens after all of this - there still may be changes in the release branch before the beta tag is created

[weswigham]

I've setup an action to create release branches. To do the VS half, it should just need another step at the end for sending a request to trigger a pipeline on the VS devops instance that sets up the new sync target.

The more open question is the preferred way to start this whole new-release-branch workflow. In devops, that's an easy question to defer, as I can always say "well, just trigger it by hand in devops", but not so for GH actions - these need to be wired into something to fire off the build request (since GH has no UI for manually triggering a workflow). I could add an @typescript-bot github comment trigger; but our release process doesn't have, like, a "release tracking issue" (like VSCode does), so there's no natural issue to make a comment on. I could add the functionality to our teams bot, but, per daniel, "Oh right, teams doesn't work on mobile [without intune enrollment which nobody is going to do]".

Should we change our release process to have a release tracking issue? Should we still wire it up with teams as a chatbot despite its shortcomings? Should we be extra-special and make a web frontend for release management (seems like overkill, IMO)?

[weswigham]

There is now a @typescript-bot create release-X.Y task that can be used in issues. Ideally, it should be used in a release tracking issue (where anything to do pertaining to the upcoming release process can be collected).

I can prepare tasks for the other common release branch activities, like syncing with master (for pre-RC), doing an LKG (if a cherry-pick-and-LKG command on a PR is insufficient), changing the release tag+version (from 0-beta to 0-rc to .1, to .2 and beyond), and, hopefully, triggering the final publish task.

With all that in place, all we should need is appropriate triggers for the VS SDK builds, right?