Repository navigation
September endgame #59271
Description
Activity
Add this to the iteration plan and Wiki? Matt Bierner (@mjbvz)
Could you use dates instead of days of the week for these?
… also even though it has been said before that the release can be expected to be done in the week AFTER the month is over, why does literally the second line in this issue already contradict that?
September 28 Endgame done
(And why not plan to be ready actually AT the end of the month?)
But I agree with Mike Pateras (@paterasMSFT) that it would be a bit easier to follow along if there were dates instead of just "Monday" etc.
Thomas Krajacic (@tkrajacic) "Endgame done" indicates the time in which the "endgame week" ends, we normally release the following week in "debt week". See https://github.com/Microsoft/vscode/wiki/Development-Process#inside-an-iteration
Daniel Imms (@Tyriar) The fact that I would have to look that up somewhere is precisely my point. This is not meant as bashing the work but rather pointing out that it can be confusing for no obvious reason.
Maybe we can add and item to the dates to better inform the community, like
- September 24 Code freeze for the endgame
- September 28 Endgame done
- October 4 Release (And keep this updated, in case the release slips)
in both the plan issue and endgame issue.
Reacted by Mike Pateras, Thomas Krajacic, Connor Shea, Joel Hock, Zulfikar, myfairsyer, ik0r, Danila Malyutin and Soichiro MikiI would also appreciate dates on these 👍
We should probably also link to the wiki in the endgame template.
- locked and limited conversation to collaborators
on Nov 23, 2018
Monday
Tuesday
Wednesday
Thursday
candidate)Friday
insiderbuilds endgame masterMonth_Year.mdin this repo directoryFriday/Monday
release/<x.y>got created and that translation should be pulled from there and that the pull request has to be created against that branch endgame masterMonday - Wednesday
release/<x.y>endgame masterInsiderfromrelease/<x.y>endgame masterInsiderendgame masterWednesday/Thursday
HEADofrelease/<x.y>in formatx.y.z(for vscode.d.ts download) endgame masterinsiderbuilds 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>ownercandidateissues, and if they pass the review assign them to the recovery milestone teamcandiatefixes are peer reviewed and pushed tomasterand then cherry-picked into the release branch teaminsidersbuild frommasterinsidersteamstablefor all platforms from release branch ownerstablebuild and theverifiedlabel is added ownerhttps://github.com/Microsoft/vscode/compare/release/<x.y>to ensure no other commits have been made in the release branch ownerHEADofrelease/<x.y>in formatx.y.z