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
Acknowledge pull requests in release notes. We acknowledge PRs from outside the team. Use the thankyou tool to generate the initial contents of the section. owner
We release a recovery build with a handful of critical fixes and translation updates a few days after a release. The candidate fixes are reviewed by the development team and are assigned to the recovery milestone. We want to be restrictive about the included candidates. The mindset is "we will lose users if we do not include the fix". Here are some examples:
data loss
a regression that users complain loudly about in issues or twitter
a significant performance regressions
an issue that impacts many users as indicated by telemetry data
an embarrassing UI glitch
critical security fixes
an issue that impacts extensions or is an API regression
Check list
Create a milestone <Month> Recovery <year>owner
Bump the version number owner
Assign candidate issues to the recovery milestone team
Review the candidate issues, and if they pass the review assign them to the recovery milestone team
All candidate fixes are peer reviewed and pushed to master and then cherry-picked into the release branch team
Initiate insiders build from master
Issues are tested in the insidersteam
Build stable for all platforms from release branch owner
Schedule Template
Monday
Tuesday
Wednesday
Thursday
candidate
)Friday
insider
builds @dbaeumerMonth_Year.md
in this repo directoryNOT MERGED - PLS REVIEW
. endgame masterFriday/Monday
Monday - Wednesday
release/<x.y>
endgame masterInsider
fromrelease/<x.y>
endgame masterInsider
endgame masterWednesday/Thursday
HEAD
ofrelease/1.31
in format1.31.0
(for vscode.d.ts download) endgame masterinsider
builds endgame masterRecovery Build
We release a recovery build with a handful of critical fixes and translation updates a few days after a release. The candidate fixes are reviewed by the development team and are assigned to the recovery milestone. We want to be restrictive about the included candidates. The mindset is "we will lose users if we do not include the fix". Here are some examples:
Check list
<Month> Recovery <year>
ownercandidate
issues, and if they pass the review assign them to the recovery milestone teamcandidate
fixes are peer reviewed and pushed tomaster
and then cherry-picked into the release branch teaminsiders
build frommaster
insiders
teamstable
for all platforms from release branch ownerstable
build and theverified
label is added ownerhttps://github.com/Microsoft/vscode/compare/release/<x.y>
to ensure no other commits have been made in the release branch ownerHEAD
ofrelease/1.31
in format1.31.x
The text was updated successfully, but these errors were encountered: